Gate-keeping persistence

AIRport has a very useful feature: all objects passed into @Api() methods get updated with the latest state (when they are returned back to the Client). This is very useful - the Client doesn't have to re-query the object to get the latest state: less code to write and maintain (and faster applications). But, there may be cases where this becomes problematic.

AIRport uses hidden state in the entity objects to keep track of the original state of those objects. This was done to avoid the complexity of managing a database session (a la Hibernate) and also removes the need for an extra query to get the original state of an object (when performing an update on that object). Plus, querying for the current state of an object in the database does not work when that object was modified by another operation. This is expecially true for modern SPA applications where the user might keep the page with modifications open for a long period of time, before submitting. In that case, modifications made by the other (remote) operation will get inadvertently reverted.

The edge case

There is an edge case in AIRport where an object might be saved even if the developer did not intend to save it. This will happen if the user modifies the object in the Client and then passes it in as a nested object to a "save" operation of another object.

This is an anti-pattern and really should never be done by developers. And even if this happens, it is largely mitigated by AIRport running "save"s within repository boundaries.  Since repositories are meant to be small and focused (and often time-bound) the chances of the Client wanting to perform multiple update operations in separate @Api() calls (and making all of the modifications before calling either one of the @Api() calls) are slim to none. But, it is technically possible.

For example in Votecube (the first application being written with AIRport) Ideas can stem from other Ideas.  When saving a new idea the parent idea is passed in to signify that this is the case. The Votecube App wants to persist the child Idea but doesn't want to update the parent (in case it was modified for some reason).

In the case described above Ideas will live in separate repositories and the operation will be repository-scoped (as is the default case for AIRport).  But one could imagine a scenario where a @CrossRepository operation passes in an object graph and some of the objects where modified in the Client (possibly inadvertently and weren't intended for persistence).

Note that this really isn't any different from the current state of things. This is exactly how a save operation will work in Hibernate. But, unfortunatelly I can't think of any way to make AIRport handle this better, besides it's nature of breaking data into Repositories.