Andrus Adamchik <andru..bjectstyle.org> wrote:
> Well, adding an object to a to-many relationship modifies the source
> object of such relationship. There are a few reasons to treat such
> objects as modified even though no SQL will be generated for them on
> commit (there was some discussion on this list some time back).
> Technical reason - flattened relationships will stop working. Purely
> logical - changing one of the object properties modifies the object,
> hence - the state change.
Yes, I asked this question on the user mailing list and got no answer, so I
figured I'd rephrase it :)
I did suspect/note both of the points you made above in my original message.
I tried a search on the mailing lists for the discussion before bringing it
up, but couldn't find anything relevent.
> Having said that I guess we should be smarter about read-only entities.
> For one thing (unrelated to the present discussion) class generation
> shouldn't produce any setters, only getters. This will explicitly show
> the user that the object is not for modification.
My own class generation templates already only generate getters. It'd be
pretty easy for me to produce a patch for this against the standard
templates if you'd like. I warn you that my read-only objects can still
have one-to-many relationships, though :)
> As for 1..n relationships when to-one is read-only....Maybe instead of
> fast failure in commit, first check for db-level modifications, and
> ignore purely object-level changes, like to-many array modification....
> So the object will still be MODIFIED until commit is executed. After
> that it will become COMMITTED even if nothing was saved for this object.
That works for me. I started my research by checking to see if there was a
read-only dbEntity flag in addition to the objEntity read-only flag, but I
didn't see one. I knew that there must be reason why the code was the way
it was (and correctly suspected the reason), but I still need working code
:) As things stand, it seems to me that the PersistentState variable
implements db-level changes, not object-level changes. Maybe there should
be another such variable rather than trying to overload it with two
meanings?
Is there anything I can do to help this process along? I hate having to run
a hacked version of Cayenne.
-Mike
This archive was generated by hypermail 2.0.0 : Wed Sep 24 2003 - 20:47:43 EDT