This mail is probably spam. The original message has been attached
along with this report, so you can recognize or block similar unwanted
mail in future. See http://spamassassin.org/tag/ for more details.
Content preview: (1) I implemented Validatable. It would be cool if
people could try this out and see if anything extra is required here.
(2) You may now use the <composite-id> declaration to specify
properties of the persistent class itself as the id properties. The
form of the declaration is: [...]
Content analysis details: (9.30 points, 8 required)
NO_REAL_NAME (3.0 points) From: does not include a real name
X_MAILING_LIST (0.0 points) Has a X-Mailing-List header
FOR_FREE (6.0 points) BODY: No such thing as a free lunch (1)
HTML_00_10 (1.2 points) BODY: Message is 0% to 10% HTML
KNOWN_MAILING_LIST (-0.9 points) Email came from some known mailing list software
--- Begin Message ---
(1) I implemented Validatable. It would be cool if people could try this
out and see if anything extra is required here.
(2) You may now use the <composite-id> declaration to specify properties of
the persistent class itself as the id properties. The form of the
declaration is:
<composite-id> <!-- name and class attibutes are missing -->
<property name="foo"/>
<property name="bar"/>
</composite-id>
to load() an instance, simply instantiate an instance of the class, set its
id properties and call:
session.load(object, object);
(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:
Essentially I have scrapped the notion of a cascaded update(). The
functionality performed by cascaded updates is now performed every time the
session is flushed.
This means that any lifecycle objects are automatically updated or saved as
soon as they are detected (in a collection or many-to-one association). The
choice of update() or save() is still made on the basis of wether or not
the id property is null.
There are still some remaining wrinkles here:
* objects with primitive ids can't have null ids. Should we interpret 0 as
null?
* the treatment of a transient object with a non-null id is different
between save() and flush(). A cascaded save() would cause the object to be
save()d whereas if discovered at flush-time, it would be update()d. Should
we tweak the semantics of cascaded saves? (Such a change has a fairly large
potential to break existing code.) Alternatively, should we reintroduce
cascaded update as a concept and tweak the new behaviour of flush() to be
consistent with save()? Or is the new behaviour actually fine?
Everyone should be aware that, even though this looks a lot like
"persistence by reachability", it still isn't because delete() remains a
manual process. I have very many misgivings about introducing any kind of
reference-counting scheme to solve the garbage collection problem...
Gavin
P.S. After this email, I will be recieving mail mainly at
[EMAIL PROTECTED]
(thanks to Anton + to Christoph who also offered me use of a mail server)
-------------------------------------------------------
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
--- End Message ---
