Value of table-specific varint in `_id` diverges in local development deployment
Hi, we would like to get local development deployments working for our repository in order to easily spawn background agents.
I have created an import script that uses
npx convex import to import a JSONL file to a table, and this works well for copying over data from production into development.
However, when I create a local development deployment using npx convex dev --local, I notice that the first characters of _id in a table is different than in the same table in cloud prod/dev. This is causing the npx convex import command to raise an error, because it detects mismatching _id formats.
Is this a bug, or is it intended behavior? If the latter, does that mean that you can't import documents from prod/dev into local development while retaining document system fields?5 Replies
Some more diagnostics: when I delete my local development deployment and create a new one, the first characters of
_id are consistent to the previous local development deployment.
So still not the same structure as in cloud dev/prod, but at least consistent across different local development deployments.Hey @Jules! The behavior you experienced is expected behavior.
Internally each table in Convex has an ID, and this ID can vary across deployments of the same project. This table ID is encoded as part of IDs, which is why you’re seeing different first characters in
_id
Now if you import rows into a new table, if I remember correctly the import process will ensure that the table ID is kept the same so that the IDs from the other deployment can be preserved. But this doesn’t work if you’re appending data to an existing table, as its ID is already setAh okay. What's interesting though is that the
_id prefixes seem to be completely consistent across production and my cloud development deployment. I also didn't use npx convex import to initially fill the tables in my cloud development deployment. That's why I would have expected that a local development deployment also had this behavior.
However you're saying that it should still work when I run npx convex import on an empty table? That would be great, I will check if that works later todayIt’s possible that the table IDs match coincidentally if they were allocated in the same order in both deployments
Right, thanks for the info 👍