Re: [Hibernate-devel] proposed API change

[Jon L. <jon...@xe...>]

I like this change...  All of the developers I have introduced Hibernate to
have had this problem.  They all thought (because of the names of the
methods) that each method would do what the other one did.

My 2 cents...

Jon...

----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: <hib...@li...>
Sent: Sunday, August 25, 2002 7:57 AM
Subject: [Hibernate-devel] proposed API change


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