Re: [SQLObject] Temporary Objects (I'm going in!)

[Paul C. <pa...@pa...>]

On Tuesday, April 29, 2003, at 01:17 PM, Luke Opperman wrote:
>
> 4. does persisting any object persist all temp objects it touches?
> This makes sense from the example above: create a tempPerson, start
> adding temp employees to it, I'd like to simply persist tempPerson
> and have it handle the rest. but does it work the other way (persist
> one of the employees, and the whole tree/graph is persisted)? Should
> there be an alternate way to persist just one? (In the context of a
> transaction this becomes particularily important: when do things I
> didn't explicitly add to the transaction but that are changed via
> join/FK get persisted?)
>

Although I am just an interested observer here I would say that I am 
slightly concerned that this proposal may add significant complexity to 
support what I believe to be a marginal set of cases.

I believe that the simplicity and cleanness of the SQLObject interface 
and orthogonality with the underlying database functionality is a 
strong selling point. In particular delegating the 'hard' transactional 
aspects to the database (effectively ignoring them at the ORM layer) 
and where necessary requiring the object to sync with the database (by 
turning _cacheValues off) strikes me as a pragmatic choice particularly 
for web applications where concurrent access is required (though 
possibly pessimistic in some scenarios)

Trying to build a generic object store capable of persisting an 
arbitrary object graphs in a coherent/transactional manner together 
seems to be excessive and probably impossible if you are trying to 
support concurrent access from multiple processes (without implementing 
coherent distributed faulting).

PaulC