#immutable schema field

18 messages · Page 1 of 1 (latest)

static pilot
#

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

night locustBOT
#

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!

pliant hearth
#

(i'm writing a Stack article with more examples)

static pilot
#

Omg you just dropped a bomb with that link! Triggers are awesome, is this out?

pliant hearth
#

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...

static pilot
#

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

pliant hearth
#

not announced yet. 🤫

static pilot
#

Since we came from firebase functions

pliant hearth
#

glad you're excited 😄

amber sapphire
#

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. 🥳

static pilot
#

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

static pilot
#

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?

pliant hearth
pliant hearth