I like the idea of making it more consistent. That will make it easier to use.
I personally would vote for defaulting cascade-to-save to null since I don't use primitives as ids. It might be worth finding out how many folks use primitives vs. objects as ids before choosing a default. Regards, John -----Original Message----- From: Gavin King [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 9:11 PM To: hibernate list Subject: [Hibernate] Re: New functionality in CVS > (3) After fielding so much user confusion over the semantics of cascade > ="all", I found a way to extend the functionality consistent with the > current semantics and (hopefully) without any risk of breaking existing > code. I will need some feedback about the details here, though: > > There are still some remaining wrinkles here: > * objects with primitive ids can't have null ids. > * the treatment of a transient object with a non-null id is different > between save() and flush(). Okay, hows this for an approach to unifying the semantics of cascade + at the same time adding some extra flexibility: * no cascades ever occur from an update() as is the case in CVS now * Cascades that occur from a save() and cascades that occur from a flush() should behave *exactly* the same as far as the user is concerned (there is a very slight difference in implementation because of the foreign key constraint issue). * The decision of when to save() a child and when to update() it is made by the user in the mapping file. The user would specify an id value that indicates "save" in the id tag (or somewhere), eg. <id name="id" type="string" cascade-to-save="null"> <generator class="uuid.hex"/> </id> <id name="id" type="string" cascade-to-save="any"> <generator class="assigned"/> </id> <id name="id" type="long" cascade-to-save="-1"/> <generator class="native"/> </id> The allowed values of the cascade-to-save attribute would be: "null" (cascade to save when id is null, cascade to update otherwise) "any" (always cascade to save) a value (cascade to save when id has that value, update otherwise) "none" (always cascade to update) Two choices: If not specified in the mapping file, we would default to "any". This change would break some existing systems that are using update() to save() newly instantiated children. However, it would be a very simple mapping file change to make those systems work again (add cascade-to-save="null"). How does everyone feel about this? I am aware that this is a fairly significant change so if anyone thinks I'm going off the deep end with this, please speak up. My justification for all this is * it feels more like an extension of existing functionality rather than a complete discontinuity. * to the extent that it is discontinuous, it is a normalization of existing semantics * this is in response to user feedback The end result of these changes should be, as far as the user is concerned: If you want a child object to be persisted, you simply reference it from the parent. You don't need to worry anymore about which circumstances result in an implicit save(), an implicit update() or nothing. On the other hand, if you want a child to be deleted you either delete the parent while it holds a reference to the child OR you delete the child itself. My view is thats a big improvement as far as understandability is concerned. The fact that I could express the expected behaviour in one paragraph is evidence for that assertion. opinions? Gavin ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
