It would be great if Modli could provide adapters with a base class to extend (or dynamically insert a default patch method through other means, if that makes backward compatibility impossible) that, by default, would use the adapter's own read() method, apply the changes, and then call the adapter's own update() method. That way, if the given DB doesn't have a way to patch data in-place, the method still works as expected.
Ideally, a patch would be applied in an ACID-compliant way; meaning, if the polyfill above were used, it would obtain a mutex read/write lock on the target object before reading and updating it. This can happen in a future iteration if necessary, as Modli doesn't currently guarantee any level of ACID compliance over what the DB engine itself provides, but options there might include requiring the target DB to have the read-on-write functionality necessary to support locking, or even support an external locking mechanism such as Redlock for a more scalable/distributed solution.
Beyond this, all we really need for this to happen at the highest level is documentation to make patch() (or any chosen function name) consistent between adapters.
It would be great if Modli could provide adapters with a base class to extend (or dynamically insert a default patch method through other means, if that makes backward compatibility impossible) that, by default, would use the adapter's own read() method, apply the changes, and then call the adapter's own update() method. That way, if the given DB doesn't have a way to patch data in-place, the method still works as expected.
Ideally, a patch would be applied in an ACID-compliant way; meaning, if the polyfill above were used, it would obtain a mutex read/write lock on the target object before reading and updating it. This can happen in a future iteration if necessary, as Modli doesn't currently guarantee any level of ACID compliance over what the DB engine itself provides, but options there might include requiring the target DB to have the read-on-write functionality necessary to support locking, or even support an external locking mechanism such as Redlock for a more scalable/distributed solution.
Beyond this, all we really need for this to happen at the highest level is documentation to make patch() (or any chosen function name) consistent between adapters.