From: Christoph S. <ch...@sc...> - 2003-01-02 11:09:28
|
hey all and happy new year Gavin King wrote: > Well, I imported the Hibernate2 sourcetree last night. Its in > its own module which means that for the next couple of months > we need to be *very* careful about handling patches. Bugfixes > and minor improvements must be applied against *both* trees. > (New features need only go into the Hibernate2 module.) As > promised, the following changes were made: > > * packages are now net.sf.hibernate.* > * project structure is changed; all java is now in src dir > * code and tests relating to toplevel collections and subcollections > was removed > > I have created a new hibernate-mapping-2.0.dtd, since we no > longer need the <collection>, <subcollection>, <generated-key> > elements and since collections may no longer appear beneath > the root element. > > In the new DTD, I have also renamed the 'readonly' attribute to > 'inverse', since its name was causing all kinds of confusion for new > (and not-so-new) users. > > Please vote on the following proposals: > > * Rename the 'role' attribute to 'name' in all collection > elements in the new DTD, for consistency with <many-to-one>, <id> > and <property> elements. The role attribute no longer > has any extra semantics beyond being a simple property > name. > > I am +1 > +1 > > * Change the default for unsaved-value to "null" in the new DTD. The > current default is surprising to new users. > > I am +1 > +1 > > * Change the default for default-cascade to "save-update" > in the new DTD. > > I am undecided ... interested to hear the views of others. > +0 > > * Remove the exception that occurs if you save an object > that is already associated with the session. This > makes save() consistent with saveOrUpdate(). > > I am probably a +1 on this > +1 > > * Remove the exception that occurs if you delete an object > that is already deleted in that session. > I am undecided. The current behaviour forces people to > think about who "owns" an object, who is responsible for > deleting it. However, it *can* be a pain in the ass. > In particular it means that: > > session.delete("from o in class java.lang.Object"); > +1 > > > |
From: Gavin K. <Gav...@ex...> - 2003-01-03 04:04:13
|
> * Rename the 'role' attribute to 'name' in all collection > elements in the new DTD, for consistency with <many-to-one>,=20 > <id> and <property> elements. The role attribute no longer > has any extra semantics beyond being a simple property > name. Done. > * Change the default for unsaved-value to "null" in the new=20 > DTD. The current default is surprising to new users. Done. > * Change the default for default-cascade to "save-update" > in the new DTD. We will leave this the way it is. > * Remove the exception that occurs if you save an object > that is already associated with the session. This > makes save() consistent with saveOrUpdate(). Lets make this change. > * Remove the exception that occurs if you delete an object > that is already deleted in that session.=20 Lets make this change also (for consistency). Max, I don't see=20 much value in making this configurable. We don't want to spawn=20 millions of config properties for minor issues like these. ********** CAUTION - Disclaimer ********** This message may contain privileged and confidential information. If you are not the intended recipient of this message (or responsible for delivery of the message to such person) you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error, you should destroy it and kindly notify the sender by reply e-mail. Please advise immediately if you or your employer do not consent to Internet e-mail for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Expert Information Services Pty Ltd ("The Company") shall be understood as neither given nor endorsed by it. The Company advises that this e-mail and any attached files should be scanned to detect viruses. The Company accepts no liability for loss or damage (whether caused by negligence or not) resulting from the use of any attached files. **EIS******** End of Disclaimer ********** |
From: Max R. A. <ma...@eo...> - 2003-01-03 20:15:48
|
> * Remove the exception that occurs if you save an object > that is already associated with the session. This > makes save() consistent with saveOrUpdate(). >Lets make this change. > * Remove the exception that occurs if you delete an object > that is already deleted in that session. >Lets make this change also (for consistency). Max, I don't see >much value in making this configurable. We don't want to spawn >millions of config properties for minor issues like these. <snif> ;( bummer.... The methods will still throw an exception if I delete/save the same entity with two different instances, or ? e.g. Person p1 = s1.load(Person.class, 42); Person p2 = s2.load(Person.class, 42); // P1 and P2 are same entity, but two different instances s1.delete(p1); s1.delete(p1); // will now not throw an exception s1.delete(p2); // would be nice if it blew.... (and the same for save()) That would ensure that I can still be "notified" if someone has "screwed" up their save/delete sequence... /max |