Re: [Hibernate] Re: New functionality in CVS

[Christian M. <vc...@cl...>]

I vote for this, it will be so much cleaner that way and as you pointed out,
fixing current code is only a matter of editing metadata files..

Regards
Christian Meunier
----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "hibernate list" <hib...@li...>
Sent: Thursday, September 05, 2002 4:10 AM
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
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>