immutable schema field
I guess the only way to do this atm is with a db writer wrapper? Would be a pretty useful helper imo!
By marking a field as immutable, once it’s value is set it cannot be changed just to be clear
14 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
yep db writer wrapper would work https://github.com/get-convex/convex-helpers/blob/lee/triggers/packages/convex-helpers/README.md#triggers
GitHub
convex-helpers/packages/convex-helpers/README.md at lee/triggers · ...
A collection of useful code to complement the official packages. - get-convex/convex-helpers
(i'm writing a Stack article with more examples)
Omg you just dropped a bomb with that link! Triggers are awesome, is this out?
yep just released yesterday 🙂
it's not technically published yet, but here's a sneak peak of the article draft https://stack.convex.dev/triggers
Triggers
Triggers automatically run code whenever data in a table changes! A new library in the convex-helpers npm package adds trigger functions to your Conve...
Missed the announcement but how exciting, we’ve been waiting for this for a long time
Might have been the first question i asked on this discord actually
not announced yet. 🤫
Since we came from firebase functions
glad you're excited 😄
More excitement over here! Our upcoming migration at work from Airtable to Convex will absolutely benefit from this. We use Airtable automations a ton, and this will make the shift that much easier. 🥳
From the stack post:
You can implement the write side of row-level security with triggers.Is this the recommended approach? How should we think of one vs the other? Especially for cascade deletes, it would be so nice if changing data in the dashboard would also have the option of triggering functions... Not sure how hard it is to support this on your side In terms of project set up: can I define this one file
const triggers = new Triggers<DataModel>();
and then call triggers.register in a bunch of other files and then something like this:
export const mutation = customMutation(rawMutation, triggers.customFunctionWrapper()); in another file?the stack post isn't complete yet, and one of the things we're discussing is how much to recommend
You need all of the triggers to be registered before the customMutation is constructed. They can be registered in separate files but all of those files need to be imported (incl. transitively) by the file that runs the mutation
i see, would be great to mention this and I'd definitely appreciate a recommendation/best practice