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: In this post:
http://sourceforge.net/forum/forum.php?thread_idr2838&forum_id8638
Yaron Zakai makes a suggestion I quite like. [...]
Content analysis details: (8.10 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)
KNOWN_MAILING_LIST (-0.9 points) Email came from some known mailing list software
--- Begin Message ---
In this post:
http://sourceforge.net/forum/forum.php?thread_id=722838&forum_id=128638
Yaron Zakai makes a suggestion I quite like.
I've seen that new users often have trouble realizing they need to use
insert() instead of save() when they want to use application-assigned ids.
People seem to expect that the "assigned" id generator will just use the
existing id of an object when you call save().
Secondly, some people would like insert() to cascade to insert(). Whereas
other times insert() to save() is appropriate.
So I would like to deprecate the following methods:
Session.insert(Object)
Session.insert(Object, Serializable)
and add the following method
Session.save(Object, Serializable)
(which does exactly what Session.insert(Object, Serializable) used to do.)
Then we would deprecate the IDGenerator interface and replace it with:
public interface IdentifierGenerator {
public Serializable generate(SessionImplementor session, Object entity)
throws ..... ;
}
Then the assigned id generator would return the current value of the
entity's id property, instead of throwing an exception.
So instead of:
session.insert(o)
you use
session.save(o)
This would allow a save() to cascade to either an "insert" or a "save"
depending upon the id generator in use. You can still always assign your
own id (regardless of what id generator is used) by calling
session.save(o, id)
In favor of this change:
* it won't break any existing code
* its more flexible
* its more understandable to new users
* its very easy to implement
On the downside, it requires deprecations of methods on the central API
interface, which is not something that should be done without due
consideration.
NEways this feels right to me. Opinions?
-------------------------------------------------------
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 ---
