feat: Add a new readonly property to Model fields definition

[diosney]

readonly will be a boolean property by default set to false.

Its operation can be something like:

• when an instance is created or updated, if the field haven't a value yet, then can be set without triggering a readonly error.
• once the field has a value, any further modification attempt will trigger a readonly error.

This come in handy when manipulating this kind of fields, which is a common use case I think (I've the need of this kind of model fields across several different projects).

So, what do you think?

[diosney]

http://stackoverflow.com/questions/29499051/a-sequelize-column-that-cannot-be-updated
Automattic/mongoose#1293

[mickhansen]

Good idea. Good candidate for a plugin

[diosney]

@mickhansen I want to do it, but I don't know where to start (I didn't found in the docs how to do sequelize plugins).

Can you point me towards the right direction so I can do it?

Thanks

[mickhansen]

I would simply wrap Instance.prototype.set, on call check model attribute for readonly, if set, check current value, if current value throw, else call original set.

[diosney]

@mickhansen Thanks, I will give it a try.

[mickhansen]

https://github.com/mickhansen/ssacl-attribute-roles does some of the same stuff, you can check out the code there.

[diosney]

Sorry, for the delay on this, I was busy on other things.

I've the doubt now, what approach will you prefer?:

• the setter method you advised
• though global hooks with beforeValidation or the combination [beforeCreate and beforeUpdate] or the combination of three of them?

Thing is that with the setter approach the readonly check can be skipped if the user set a custom setter or using raw: true right? And I would prefer to always enforce the check.

Thanks!

[mickhansen]

If you wrap the setter method you can choose to ignore the raw option.

[diosney]

@mickhansen Nice! I will continue with that option then, thanks!

[TonyNLewis]

I came across this looking for a way to create a model based on a view (db-level) that would only attempt to save the fields in the underlying base table. For example, the view might have a part number and description that are associated with a PartID. When I save the record, I don't want the related fields to be saved, just the PartID itself. It seems to me that this is truly "readonly" and the implementation being suggested is more "noupdate".

[mickhansen]

@TonyNLewis are you looking to disallow all writes (i.e. both initial and update) or just updates? Is part number allowed to be updated if it is currently null?

You could take a look at: https://github.com/mickhansen/ssacl-attribute-roles
It's not that mature yet but could be worth a try.

[diosney]

Finally got the time to do this 😄

@TonyNLewis I accepted your suggestion and named the plugin sequelize-noupdate-attributes, although readonly capabilities can be added too if someone asks for it.

I added the new plugin at the wiki https://github.com/sequelize/sequelize/wiki/Add-ons-&-Plugins

npm location: https://www.npmjs.com/package/sequelize-noupdate-attributes

Thanks @mickhansen for your help.

[reinert]

This definetly should be in core. ReadOnly option is a must have for ORMs.

[leodutra]

Please consider it as core feature, gentlemen.

[jeremybradbury]

why not something more standard like user.removeDataValue('email') inside update hooks?

Model says "oh you got an email update for me?... https://www.youtube.com/watch?v=lWtPFv194GU

[MaximilianLloyd]

Any update on this?

[OrenSchwartz]

?

[ado-astpos]

Any update?

[svendeckers]

new year, new update? :-)

[papb]

I have reopened this but it is going to be low priority, since there is already a plugin to do this

[svendeckers]

@diosney @papb Thank you!
I'm afraid the plugin doesn't work anymore, or at least I couldn't get it to work.
So really looking forward to this :-)

[Daspy11]

One year later, still would like this :)

[ShubhamPalriwala]

Let's implement this 😌

[bkimminich]

@juice-shop could really use this feature, as we're currently doing it via a third party module, but that doesn't work with TypeScript and kind of blocks our migration now.

[micodls]

Bumping this feature request :)