Add ability to configure the behavior of writing to a non-writable field#4734
Add ability to configure the behavior of writing to a non-writable field#4734green-david wants to merge 1 commit into
Conversation
| message = "attempted to write to non-writable field #{inspect(name)} during #{action}" | ||
|
|
||
| case on_writable_violation do | ||
| :raise -> | ||
| raise ArgumentError, message | ||
| :warn -> | ||
| Logger.warning(message) | ||
| _ -> | ||
| :ok | ||
| end |
There was a problem hiding this comment.
The message here likely needs to be more robust and contain additional information, open to feedback. This is just a simple message for now to illustrate the functionality.
| * `:on_writable_violation` - Defines what action to take when performing an insert or update | ||
| attempts to modify a field that should not be modified according to it's `:writable` value. | ||
| Must be one of `:nothing`, `:warn`, or `:raise`. If set to `:nothing`, the modification is | ||
| silently ignored. If set to `:warn`, the modification is ignored and a warning is logged. If set | ||
| to `:raise`, an exception is raised and the operation is aborted. If `:writable` is set to `:always`, | ||
| `:on_writable_violation` must be set to `:nothing`. Defaults to `:nothing`. |
There was a problem hiding this comment.
I added this as "the path of least resistance" to illustrate the functionality, but I am not confident this is the desired way forward as to the public facing API of how to configure this behavior.
Some other options:
writable: [when: :never, on_violation: :raise]
writable: {:never, :raise}
writable: [:never, :raise]
Open to suggestions :)
|
Looking at the code, I like the on_writable_violation approach. However, I wonder if the implementation should be |
|
WDYT? |
2 participants
This PR adds the ability to change the default behavior of silently ignoring changes to non-writable fields as discussed on the mailing list.
Attempting to write to a non-writable field can lead to code which appears to update the field but actually doesn't, leading to confusing behavior or hidden bugs. By allowing the user to specify that a warning should be logged or an exception raised, these errant writes can be detected and remedied.