Will it always be safe to mutate the return value of Table.get()?

[axefrog]

Without getting into questions surrounding the safety of mutations in software architecture in general, I notice that right now when I call Table.get(), it always constructs a new object for the output record and doesn't seem to rely on the state of that object thereafter. This suits me fine because I need an exact copy of that record that is safe to mutate as part of the way I maintain application state over time. If Dexie is always guaranteeing a fresh object for me, that I can do with as I will, then I can directly use what it returns and avoid the (admittedly minor) overhead of redundantly cloning it to a new object.

So my question is this: Even though Dexie currently gives me an object that is (seemingly) safe for me to take ownership of and mutate to my heart's content, is this just the result of an implementation detail and should not be relied upon for safety in future iterations of Dexie, or is it a deliberate design decision that I can base assumptions on even in new versions of Dexie in the future?

[axefrog]

@dfahlander Not sure if you have seen this?

[dfahlander]

Sorry, I missed it. Yes it's safe to mutate any returned value from Dexie's Table.get(), toArray(), etc.

However, Dexie 4 might put new constraints on values returned in pure readonly scopes, as callbacks in liveQuery() and useLiveQuery() as they might return cached immutable data. This is not yet decided on. We could decide to continue returning mutable clones of the values instead, but for performance reasons I am leaning towards returning immutable freezed objects and arrays when querying data within liveQuery() scopes.

So basically, if your code wants to mutate data by getting an object, modify it and put back a modified version, for example within a 'rw' transaction (or outside transaction) that will always be ok, also in future versions of Dexie, but if you are doing pure readonly queries that may be executed from a liveQuery() callback, this should be avoided until we know for sure what the constraints will be in Dexie 4.

[axefrog]

Okay, thanks, that was helpful :)