hibernate-devel

RE: [Hibernate] CodeGenerator

[Aapo L. <aap...@pr...>]

> Yeah that would make more sense. Do you wanna produce a patch? (Do we 
> need to worry about backward compatibility on this?)

Maybe I could look this after I get some sleep, :-). Quick search to
source code gave me an idea. The feature I'm after can easily be patched
at the bottom of Basic Renderer (I think):

for (Iterator fields = classMapping.getFields().iterator();
     fields.hasNext();) {
  
  field = (Field) fields.next();

  // Some code removed.

  // setter
  writer.println("    public void set" +
  field.getAsSuffix() + "(" + getTrueTypeName(field, class2classmap)
  + " " + field.getName() + ") {");
  writer.println("        this." + field.getName() +
  " = " + field.getName() + ";");
  writer.println("    }");
}

> P.S. We also need someone to patch CodeGenerator to handle 
> <one-to-one> associations. They are ignored at present, apparently.

I have started using Hibernate just a few weeks ago, and I'm not very
confident that I know enough of this, but I can look this next week when
I have more time.

Regards
Aapo </b>ungle Laakkonen

RE: [Hibernate] CodeGenerator

[Gavin K. <Gav...@ex...>]

Well, its probably best to implement equals() and hashCode() if you
plan on keeping it in a Set. But since Hibernate guarantees =3D=3D is
preserved for objects in the same Session, even thats not vital,
as long as you are carefull not to mix and match objects from
different sessions. And its up to you to decide whether you should=20
use primary key values of property values to determine equality.=20

So basically theres nothing specific to Hibernate in your decision=20
to implement equals() or hashCode(). Usually I don't bother.

On the other hand, you *must* implement equals() and hashCode() for:
* a composite-id class
* a persistent class with an "embedded" composite-id


> Is it recommended that all hibernate persistent classes implement
> equals() and hashcode()?  If so, is it possible to implement=20
> them in a base class?  I'm doing this write now with the=20
> following toString() method and it works pretty well:
>=20
>     public String toString() {
>         StringBuffer results =3D new StringBuffer();
>         Class clazz =3D getClass();
>=20
>         results.append(getClass().getName() + "\n");
>=20
>         Field[] fields =3D clazz.getDeclaredFields();
>=20
>         try {
>             AccessibleObject.setAccessible(fields, true);
>=20
>             for (int i =3D 0; i < fields.length; i++) {
>                 results.append("\t" + fields[i].getName() + "=3D" +
>                                fields[i].get(this) + "\n");
>             }
>         } catch (Exception e) {
>             // ignored!
>         }
>=20
>         return results.toString();
>     }
>=20
> Thanks,
>=20
> Matt
>=20
> > -----Original Message-----
> > From: hib...@li...
> > [mailto:hib...@li...] On=20
> > Behalf Of Gavin King
> > Sent: Sunday, December 29, 2002 4:09 AM
> > To: hib...@li...
> > Subject: [Hibernate] CodeGenerator
> >=20
> >=20
> >=20
> > Hi everyone,
> >=20
> > I spent some time earlier today playing around with
> > CodeGenerator (a part of the codebase that I'm only=20
> > barely familiar with) and made some improvements.
> >=20
> > * The support for <composite-id> is now working
> >   properly with composite id classes having
> >   correctly generated hashCode() and equals()
> >   methods.
> >=20
> > * All generated classes now implement toString()
> >=20
> > The generated classes now have a dependency upon=20
> commons-lang, which=20
> > doesn't bother me in the slightest, but other people may=20
> have another
> > opinion.
> >=20
> > 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.
> >=20
> > 1.2.1 should be released before the weekend.
> >=20
> > peace
> >=20
> > Gavin
> >=20
> >=20
> > ********** CAUTION - Disclaimer **********
> > This message may contain privileged and confidential
> > information. If you are not the intended recipient of this=20
> > message (or responsible for delivery of the message to such=20
> > person) you are hereby notified that any use, dissemination,=20
> > distribution or reproduction of this message is prohibited.=20
> > If you have received this message in error, you should=20
> > destroy it and kindly notify the sender by reply e-mail.=20
> > Please advise immediately if you or your employer do not=20
> > consent to Internet e-mail for messages of this kind.=20
> > Opinions, conclusions and other information in this message=20
> > that do not relate to the official business of Expert=20
> > Information Services Pty Ltd ("The Company") shall be=20
> > understood as neither given nor endorsed by it.
> >=20
> > The Company advises that this e-mail and any attached
> > files should be scanned to detect viruses. The Company accepts no=20
> > liability for loss or damage (whether caused by negligence or not)=20
> > resulting from the use of any attached files.
> > **EIS******** End of Disclaimer **********
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > 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
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20

RE: [Hibernate] CodeGenerator

[Gavin K. <Gav...@ex...>]

> > >The generated classes now have a dependency upon=20
> commons-lang, which=20
> > >doesn't bother me in the slightest, but other people may=20
> have another
> > >opinion.
> >
> > Yes - me for one :) I would like to keep the generated code=20
> as simple=20
> > as possible :) (but at the same time I like to broaden the usage of=20
> > commons-lang)
> >
> > Thus, I'll suggest (and also make a patch as I get to it) that it=20
> > should be optional to have the dependency on commons-lang.=20
> Optimal, we=20
> > could generate a bare-boned toString method based on the=20
> > attributes/properties know to the metadata.
> >
>=20
> On second thought - I'll add an option to either have the=20
> codegenerator use the methods provided by commons-lang OR not=20
> do anything at all :)
>
> The "do nothing" option is for those who want to have either=20
> a base or their own custom subclass for their classes (nicely=20
> supported by my metaattribute patch :)

Yes, I'm happy to agree to that in the case of toString().
However, in the case of equals() and hashCode() for composite-id
classes, we actually *need* them. (Its required by Hibernate.)
I would much prefer the commons-lang dependency to trying to=20
fully generate the equals() and hashCode() methods (thats=20
actually *more* complicated).

And after this discussion, I'm leaning toward the view that
generated entity classes should implement equals() had hashCode()
consistent with identifier equality, though I suppose that should
also be optional.


> > And what about the meta-attribute thingy ? (it is not that a big=20
> > codechange compared to the recent commit :) (i'm just=20
> pushing here :)
>=20
> How about adding the meta-attribute thingy as an extra X-mas=20
> gift - it would instantly make me happy, and the=20
> codegenerator so much more better :)

After this discussion I'm finally satisfied that this is a=20
requirement if CodeGenerator is to become really useful. So I'm=20
perfectly happy to allow things like:

<class name=3D"Foo" ... >
   <meta attribute=3D"description">JavaDoc comment for Foo</meta>
   <meta attribute=3D"base-class">AbstractPersistent</meta>
   <meta attribute=3D"generated-class">FooBase</meta>
   .....
   <property name=3D"bar" type=3D"serializable" ....>
       <meta attribute=3D"description">
          JavaDoc comment for getBar()
       </meta>
       <meta attribute=3D"java-type">java.lang.Object</meta>
   </property>
   .....
</class>

The only bad thing about <meta> is its not very well self-documenting.
So we will really need a page of documentation about CodeGenerator.
Particularly since it is now maturing quite nicely :)


********** 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 **********

Re: [Hibernate] CodeGenerator

[Max R. A. <ma...@eo...>]

> > 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 :)

>Yes, I'm happy to agree to that in the case of toString().

Yup!.

>However, in the case of equals() and hashCode() for composite-id
>classes, we actually *need* them. (Its required by Hibernate.)
>I would much prefer the commons-lang dependency to trying to
>fully generate the equals() and hashCode() methods (thats
>actually *more* complicated).

Yup!

>And after this discussion, I'm leaning toward the view that
>generated entity classes should implement equals() had hashCode()
>consistent with identifier equality, though I suppose that should
>also be optional.

Yup!

> > 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 :)

>After this discussion I'm finally satisfied that this is a
>requirement if CodeGenerator is to become really useful. So I'm
>perfectly happy to allow things like:

Ok - an even more powerfull meta, than my patch :)
I'll start doing it right now :)

><class name="Foo" ... >
 >  <meta attribute="description">JavaDoc comment for Foo</meta>
 >  <meta attribute="base-class">AbstractPersistent</meta>
 >  <meta attribute="generated-class">FooBase</meta>

Okey - I get this one....(and those class references are meant to be fully
qualified names, right ?)
I'll even put in another one (the one that I currently need :)
  <meta attribute="implements">Validatable</meta>
  <meta attribute="implements">Auditable</meta>

or should that be   <meta attribute="implements">Validatable,
Auditable</meta>


 >  <property name="bar" type="serializable" ....>
 >      <meta attribute="description">
 >         JavaDoc comment for getBar()
 >      </meta>
 >      <meta attribute="java-type">java.lang.Object</meta>
 >  </property>
 >  .....

But this one ? Isn't this a bit "cloudy"....
If I understand this correctly you want that if "java-type" is provided the
codegenerator should
use that type instead of the type specified in the property....Just curious,
when is that usefull ?

></class>

>The only bad thing about <meta> is its not very well self-documenting.
>So we will really need a page of documentation about CodeGenerator.

I'll be happy to do both :)

>Particularly since it is now maturing quite nicely :)

Yes - it is isn't :)

/max

RE: [Hibernate] CodeGenerator

[Gavin K. <Gav...@ex...>]

>  >  <property name=3D"bar" type=3D"serializable" ....>
>  >      <meta attribute=3D"description">
>  >         JavaDoc comment for getBar()
>  >      </meta>
>  >      <meta attribute=3D"java-type">java.lang.Object</meta>
>  >  </property>
>  >  .....
>=20
> But this one ? Isn't this a bit "cloudy"....
> If I understand this correctly you want that if "java-type"=20
> is provided the codegenerator should use that type instead of=20
> the type specified in the property....Just curious, when is=20
> that usefull ?

For example:

<property name=3D"date" type=3D"date"/>

currently generates:

public java.sql.Date getDate();

what if you wanted

public java.util.Date getDate();

Hey, I just thought of another <meta> that would be *very* useful:

<property name=3D"bar" type=3D"String" ....>
	<meta name=3D"scope">protected</meta>
	<meta attribute=3D"description">
		JavaDoc comment for getBar()
	</meta>
</property>

surprised I didn't think of that before....


********** 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 **********

Re: [Hibernate] CodeGenerator

[Max R. A. <ma...@eo...>]

>  >  <property name="bar" type="serializable" ....>
>  >      <meta attribute="description">
>  >         JavaDoc comment for getBar()
>  >      </meta>
>  >      <meta attribute="java-type">java.lang.Object</meta>
>  >  </property>
>  >  .....
>
> But this one ? Isn't this a bit "cloudy"....
> If I understand this correctly you want that if "java-type"
> is provided the codegenerator should use that type instead of
> the type specified in the property....Just curious, when is
> that usefull ?

>For example:

><property name="date" type="date"/>

>currently generates:

>public java.sql.Date getDate();

>what if you wanted

>public java.util.Date getDate();

hmm - ok, I see your point...will look into it...

>Hey, I just thought of another <meta> that would be *very* useful:

><property name="bar" type="String" ....>
><meta name="scope">protected</meta>
><meta attribute="description">
>JavaDoc comment for getBar()
></meta>
></property>

>surprised I didn't think of that before....

I actually think about this before, but could not come to term with me in
what the scope should mean...

Its it the actual field, the getX() or the setX() that should be modified ?
(The same actually goes for the "description" tag...)

How about having "description-get", "description-set" and just "description"
for the actual field ? (or should it be "description-field"

And then similarily "scope-get", "scope-set" and "scope"/"scope-field" for
the actual field ?

Maybe "scope" and "description" should just apply for both set, get and
field if nothing else is specified ?

Any thoughts ?

/max

RE: [Hibernate] CodeGenerator

[Gavin K. <Gav...@ex...>]

> Its it the actual field, the getX() or the setX() that should=20
> be modified ? (The same actually goes for the "description" tag...)

I meant the get/set pair. Fields should always be private.
perhaps it makes more sense to have getter-scope and
setter-scope.

> How about having "description-get", "description-set" and=20
> just "description" for the actual field ? (or should it be=20
> "description-field"

I suppose....but isn't that a bit much?? I had intended that
the description would go onto the getter method.
=20
> And then similarily "scope-get", "scope-set" and=20
> "scope"/"scope-field" for the actual field ?
>=20
> Maybe "scope" and "description" should just apply for both=20
> set, get and field if nothing else is specified ?

I'd rather not grow a whole menagerie of these metas....


********** 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 **********