From: Gavin K. <Gav...@ex...> - 2002-12-29 11:09:01
|
Hi everyone, I spent some time earlier today playing around with=20 CodeGenerator (a part of the codebase that I'm only=20 barely familiar with) and made some improvements. * The support for <composite-id> is now working properly with composite id classes having correctly generated hashCode() and equals() methods. * All generated classes now implement toString() The generated classes now have a dependency upon commons-lang, which doesn't bother me in the slightest, but other people may have another opinion. The last thing I noticed, but didn't have time to fix, is that subclass constructors are unaware of superclass properties. We need to fix that as soon as possible. If anyone has a chance to address this, I would appreciate it. 1.2.1 should be released before the weekend. peace Gavin ********** 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...> - 2002-12-29 12:15:44
|
>The generated classes now have a dependency upon >commons-lang, which doesn't bother me in the >slightest, but other people may have another >opinion. Yes - me for one :) I would like to keep the generated code as simple as possible :) (but at the same time I like to broaden the usage of commons-lang) Thus, I'll suggest (and also make a patch as I get to it) that it should be optional to have the dependency on commons-lang. Optimal, we could generate a bare-boned toString method based on the attributes/properties know to the metadata. >The last thing I noticed, but didn't have time >to fix, is that subclass constructors are unaware >of superclass properties. We need to fix that >as soon as possible. If anyone has a chance to >address this, I would appreciate it. I'll look into it. >1.2.1 should be released before the weekend. And what about the meta-attribute thingy ? (it is not that a big codechange compared to the recent commit :) (i'm just pushing here :) /max |
From: Max R. A. <ma...@eo...> - 2002-12-29 17:21:54
|
> >The generated classes now have a dependency upon > >commons-lang, which doesn't bother me in the > >slightest, but other people may have another > >opinion. > > Yes - me for one :) I would like to keep the generated code > as simple as possible :) (but at the same time I like to broaden > the usage of commons-lang) > > Thus, I'll suggest (and also make a patch as I get to it) that > it should be optional to have the dependency on commons-lang. > Optimal, we could generate a bare-boned toString method based > on the attributes/properties know to the metadata. > On second thought - I'll add an option to either have the codegenerator use the methods provided by commons-lang OR not do anything at all :) The "do nothing" option is for those who want to have either a base or their own custom subclass for their classes (nicely supported by my metaattribute patch :) > >The last thing I noticed, but didn't have time > >to fix, is that subclass constructors are unaware > >of superclass properties. We need to fix that > >as soon as possible. If anyone has a chance to > >address this, I would appreciate it. > > I'll look into it. This one is more "challenging" than I thought - will take some fiddling and refactoring to do it properly....working on it (and also on making the codegen test hbm.xml files more complete/test-friendly) > And what about the meta-attribute thingy ? (it is not that a big > codechange compared to the recent commit :) (i'm just pushing here :) How about adding the meta-attribute thingy as an extra X-mas gift - it would instantly make me happy, and the codegenerator so much more better :) /max |
From: Matt R. <ma...@ra...> - 2002-12-29 12:17:21
|
Is it recommended that all hibernate persistent classes implement equals() and hashcode()? If so, is it possible to implement them in a base class? I'm doing this write now with the following toString() method and it works pretty well: public String toString() { StringBuffer results = new StringBuffer(); Class clazz = getClass(); results.append(getClass().getName() + "\n"); Field[] fields = clazz.getDeclaredFields(); try { AccessibleObject.setAccessible(fields, true); for (int i = 0; i < fields.length; i++) { results.append("\t" + fields[i].getName() + "=" + fields[i].get(this) + "\n"); } } catch (Exception e) { // ignored! } return results.toString(); } Thanks, Matt > -----Original Message----- > From: hib...@li... > [mailto:hib...@li...] On > Behalf Of Gavin King > Sent: Sunday, December 29, 2002 4:09 AM > To: hib...@li... > Subject: [Hibernate] CodeGenerator > > > > Hi everyone, > > I spent some time earlier today playing around with > CodeGenerator (a part of the codebase that I'm only > barely familiar with) and made some improvements. > > * The support for <composite-id> is now working > properly with composite id classes having > correctly generated hashCode() and equals() > methods. > > * All generated classes now implement toString() > > The generated classes now have a dependency upon > commons-lang, which doesn't bother me in the > slightest, but other people may have another > opinion. > > The last thing I noticed, but didn't have time > to fix, is that subclass constructors are unaware > of superclass properties. We need to fix that > as soon as possible. If anyone has a chance to > address this, I would appreciate it. > > 1.2.1 should be released before the weekend. > > peace > > Gavin > > > ********** 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 ********** > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > hibernate-devel mailing list hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > |
From: Max R. A. <ma...@eo...> - 2002-12-29 15:35:54
|
> Is it recommended that all hibernate persistent classes implement > equals() and hashcode()? It is always recommende to implement equals and hashCode for any class that you would consider putting into java collections or other mechanisms that tries to identity and/or sort them....so yes, it is recommende for all persistent classes (hibernate or no hibernate :) > If so, is it possible to implement them in a > base class? Yes - that is possible, but the current codegenerator (and Hibernate by design) refrain from forcing you to have an baseclass for your persistent classes. I've committed a patch (my so called metaattribute patch) that would allow the codegenerator to seamingsly (and more easily) support such constructs as common baseclasses and other fancy stuff (which should not be required by the "basic" codegeneration) > I'm doing this write now with the following toString() > method and it works pretty well: > > public String toString() { > StringBuffer results = new StringBuffer(); > Class clazz = getClass(); > > results.append(getClass().getName() + "\n"); > > Field[] fields = clazz.getDeclaredFields(); > > try { > AccessibleObject.setAccessible(fields, true); > > for (int i = 0; i < fields.length; i++) { > results.append("\t" + fields[i].getName() + "=" + > fields[i].get(this) + "\n"); > } > } catch (Exception e) { > // ignored! > } > > return results.toString(); > } This is more or less what commons-lang's reflectionToString does (which is what Gavin's patch will make the CodeGenerator do now) But what about your hashCode ? /max |
From: Matt R. <ma...@ra...> - 2002-12-29 15:47:29
|
> > This is more or less what commons-lang's reflectionToString > does (which is what Gavin's patch will make the CodeGenerator do now) > > But what about your hashCode ? > > /max > I'm looking for advice on how to implement an equals() and hashCode() method in my base class. Any suggestions are appreciated. Thanks, Matt |
From: Max R. A. <ma...@eo...> - 2002-12-29 16:03:36
|
Best and easiest advice is: Use commons-lang ;) http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/H ashCodeBuilder.html and http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/T oStringBuilder.html Regarding hashCode write your own following the guidelines written here: (which is what commons-lang has done) http://java.sun.com/docs/books/effective/chapters.html (Read Chapter 3) /max ----- Original Message ----- From: "Matt Raible" <ma...@ra...> To: <hib...@li...> Sent: Sunday, December 29, 2002 4:47 PM Subject: RE: [Hibernate] CodeGenerator > > > > > This is more or less what commons-lang's reflectionToString > > does (which is what Gavin's patch will make the CodeGenerator do now) > > > > But what about your hashCode ? > > > > /max > > > > I'm looking for advice on how to implement an equals() and hashCode() > method in my base class. Any suggestions are appreciated. > > Thanks, > > Matt > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > hibernate-devel mailing list > hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > |
From: Juozas B. <ba...@ce...> - 2002-12-29 19:54:51
|
equals() and hashCode() can be implemented using this definition : for all persistent objects a, b : a.equals(a) === true a.equals(b) ==> b.equals(a) a.equals(b) ==> a.hashCode() = b.hashCode() a is persistent ==> a.getId() != null a.equals(b) <=> a.getId().equals(b.getId()) a is persistent ==> a.hashCode() = a.getId().hashCode() > > > > > This is more or less what commons-lang's reflectionToString > > does (which is what Gavin's patch will make the CodeGenerator do now) > > > > But what about your hashCode ? > > > > /max > > > > I'm looking for advice on how to implement an equals() and hashCode() > method in my base class. Any suggestions are appreciated. > > Thanks, > > Matt > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > hibernate-devel mailing list > hib...@li... > https://lists.sourceforge.net/lists/listinfo/hibernate-devel |