Hello! I am inheriting a small typesense poc that ...
# community-help
h
Hello! I am inheriting a small typesense poc that I'm working to make production ready. We have a piece of code the upserts all values to the collection, effectively a resync. They way the current code does this is by cloning the collection schema, upserting to it, then pointing our alias to the new collection, and delete the prior version. Ok, that's 'fine' but now my terraform state loses reference to the collection, which I am using to maintain the schema. Is this flow necessary? They're suggesting it needs to be done for "zero downtime".
I guess this is the documented way. The second is to use the bulk document endpoint with upset action 'combined with delete_by'; I don't really follow what the delete_by would be used for. If I'm upserting, shouldn't it do x records 'upserted' at a time until the documents i've provided have all been added?
j
Ok, that's 'fine' but now my terraform state loses reference to the collection,
I would recommend not using terraform to maintain Typesense's collection schema structure! That would be like maintaining say MySQL or Postgres table structure using terraform. Instead you want to have your schema in your codebase, just like how you'd maintain DB migrations in your codebase
I guess this is the documented way.
Yup, this is the documented way.
The second is to use the bulk document endpoint with upset action 'combined with delete_by'; I don't really follow what the delete_by would be used for.
Upserting does not account for documents that have been deleted from your primary DB, that now need to be deleted from Typesense
🤝 1
h
Ah that makes sense. Thank you!
👍 1
Are you aware of any examples of how some people are managing their migrations? I'm wondering if I want to write it as objects in timestamped json files, and apply as go and keep track of "where" we are in the migration, very similar to traditional rdb migration patterns OR if there is a better pattern somewhere. I believe I'll need to either write my own 'migrator', which shouldn't be too bad, since it's a well established pattern.