RE: [Hibernate] Re: New functionality in CVS

[Urberg, J. <ju...@ve...>]

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:ga...@ap...]
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
hib...@li...
https://lists.sourceforge.net/lists/listinfo/hibernate-devel