Xata internal postgres fields - can I rely on them?
Hi, I'm just trying to get started with Xata (with postgres enabled).
I chose to use prisma to manage the database schema and db migrations and the xata ts client/sdk for accessing the db.
All was going well and I decided to try and set up CI/CD properly, which included checking the xata files out of git and regenerating the client (using a prisma schema as source of truth) in the CI/CD pipeline.
However after trying to pin the versions of the client and cli in my package.json and running
npx xata codegen
, I'm now seeing errors because my records are coming back from the db (via the xata ts client) like this:
whereas, before they were like this:
The errors are happening because I was relying on the xata_id
field, but it seems like the xata_id
field now needs to be accessed at id
and the other xata_
fields are now nested in a xata.
path?
My guess is that I had the @next version of the client installed and had problems with it, so I installed the @latest, which might have caused this change in the xata fields...
Is this the case that the interface for accessing these fields has changed across versions of the client, and shouldn't I be relying on these xata_
postgres fields?4 Replies
I am having the same issue on the Web-UI. Yesterday it was ok, today all the xata internal fields (xata_createda, xata_id, xata_updatedat, xata_version) appear as null, in 2 different projects
hi, I'm looking into both issues. I'm not quite sure they are the same.
I think we figured it out, we're deploying a fix
it should be fixed now, can you try it, please?
yes, it now appears!
(At least in my case, for the Web-UI issue)
ok, that's promising!, but I'm still stuck with an
invalid branch name
error (https://discord.com/channels/996791218879086662/1281543310753927270), so I can't check, unfortunately...