[Middlegen-user] Hibernate, dao and DBHelper class template error

[l***@ikke.net]

Hi,

I run the subtask hibernatDAO in the middlegen task. As mentioned before
on this list. You need to specify the variable "getHibernateSession" when
using hibernate 2.x. (I am using 2.1)

<hibernateDAO getHibernateSession="${getHibernateSession}.getSession();"/>

I have a few comments on the template.
First you need to specify the ';'. Which is not very need but okay.
The second is that the template produces a java file that is incorrect.

/**
* Insert the object into the database.
*
* @param obj The object to save.
*
* @return The primary key of the newly inserted object.
*/
public Serializable save( AttributeName obj ) throws HibernateException
{
Session hibSession =
nl.ekc.hibernate.factory.FactoryClass.getSessionFactory().openSession();
Serializable retval = hibSession.save( obj );

return serializable;
}

the return is of course not 'serializable' but 'retval'

I haven't looked at the template yet but it look like an easy fix.
Since I'm not realy sure wether I want to use the hibernateDAO, I was just
curious what it did :), I'll comment it out. But someone might find it
usefull, that's why I'm posting it.

Regards, Wouter Boers

[Ben Litchfield]

Post by l***@ikke.net
I run the subtask hibernatDAO in the middlegen task. As mentioned before
on this list. You need to specify the variable "getHibernateSession" when
using hibernate 2.x. (I am using 2.1)
<hibernateDAO getHibernateSession="${getHibernateSession}.getSession();"/>
I have a few comments on the template.
First you need to specify the ';'. Which is not very need but okay.

I would like to hear your comments on a better way to provide this
functionality. Would it be better as a merge file?

Post by l***@ikke.net
The second is that the template produces a java file that is incorrect.

This was fixed in CVS a while back but has not been released yet.

Ben

[Wouter Boers]

I can think of three ways to provide this funtionality:

1: Put it in the properties file as done now. The full name including the
methods is then the only way since you never will know if getSession() is
the correcy method. Disadvantage is that I somehow do not like this. It
feels wrong. It'n not a property it's a method call which should in the
ideal world be derived somehow (introspecion?).

2: put it in a merge file. In my opinion this is a cleaner sollution then
the first but also splits the generation of the file. The merge then becomes
a 'required' item. While as far as I have worked with the merge files, they
are intended as an extension and thus provide additional functionality to
middlegen. Not core functionality, like the hibernateDAO is.

3. Set it via the gui and store the setting in the prefs file. I put this
file under version control so I can recreate the middle/xdoclet generation
on the production system. The disadvantage is, that the default will, in
most cases not work since they are not 'local' like the other settings
stored in the prefs file.

So taking everything in consideration, the third option would be my choice.
What are your cons and pros?

As for the fix in CVS, is there a bugfix release planned, like 2.1.1? I do
not want to go into production with a CVS snapshot as you can understand.
For development I can opf course live with it.

Regards, Wouter

-----Original Message-----
From: middlegen-user-***@lists.sourceforge.net
[mailto:middlegen-user-***@lists.sourceforge.net] On Behalf Of Ben
Litchfield
Sent: 15 January 2005 03:42
To: middlegen-***@lists.sourceforge.net
Subject: Re: [Middlegen-user] Hibernate, dao and DBHelper class template
error

Post by l***@ikke.net
I run the subtask hibernatDAO in the middlegen task. As mentioned before
on this list. You need to specify the variable "getHibernateSession" when
using hibernate 2.x. (I am using 2.1)
<hibernateDAO getHibernateSession="${getHibernateSession}.getSession();"/>
I have a few comments on the template.
First you need to specify the ';'. Which is not very need but okay.

I would like to hear your comments on a better way to provide this
functionality. Would it be better as a merge file?

Post by l***@ikke.net
The second is that the template produces a java file that is incorrect.

This was fixed in CVS a while back but has not been released yet.

Ben


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

[Ben Litchfield]

Unfortunately, there isn't really a good default for this piece of code
generation. It varies depending on how people are using hibernate. The
way it is now just happens to be the simplest solution.

I would assume that most projects that use hibernate have some sort of
utility class so they can access the hibernate session in a way that
depends on their environment(tomcat/jboss/spring/threadlocal pattern/...)

I was trying to think of a way we could generate the utility class to
access the session, but I think it might be overkill, and I am unsure if
it can be good enough to handle all the cases. Something like

<hibernateDAO>
<hibernateSession>
<!-- pick one of the four options-->
<spring />
<threadLocal />
<jboss
jndiName="&#34;java:/hibernate/HibernateSessionFactory&#34;" />
<!--Where HibernateUtil must have static get/closeSession
methods-->
<custom class="com.mycompany.util.HibernateUtil />
</hibernateSession>
</hibernateDAO>

David, do you have any thoughts on this? Are we approaching this
completely wrong? Is there something that could be done on the hibernate
side to make a single entry point to obtaining a session factory no
matter what your environment is, that is somehow configured, something
like a SessionFactoryFactory


I am unsure when a bugfix release could be made available.

Ben

Post by Wouter Boers
1: Put it in the properties file as done now. The full name including the
methods is then the only way since you never will know if getSession() is
the correcy method. Disadvantage is that I somehow do not like this. It
feels wrong. It'n not a property it's a method call which should in the
ideal world be derived somehow (introspecion?).
2: put it in a merge file. In my opinion this is a cleaner sollution then
the first but also splits the generation of the file. The merge then becomes
a 'required' item. While as far as I have worked with the merge files, they
are intended as an extension and thus provide additional functionality to
middlegen. Not core functionality, like the hibernateDAO is.
3. Set it via the gui and store the setting in the prefs file. I put this
file under version control so I can recreate the middle/xdoclet generation
on the production system. The disadvantage is, that the default will, in
most cases not work since they are not 'local' like the other settings
stored in the prefs file.
So taking everything in consideration, the third option would be my choice.
What are your cons and pros?
As for the fix in CVS, is there a bugfix release planned, like 2.1.1? I do
not want to go into production with a CVS snapshot as you can understand.
For development I can opf course live with it.
Regards, Wouter
-----Original Message-----
Litchfield
Sent: 15 January 2005 03:42
Subject: Re: [Middlegen-user] Hibernate, dao and DBHelper class template
error

Post by l***@ikke.net
I run the subtask hibernatDAO in the middlegen task. As mentioned before
on this list. You need to specify the variable "getHibernateSession" when
using hibernate 2.x. (I am using 2.1)
<hibernateDAO getHibernateSession="${getHibernateSession}.getSession();"/>
I have a few comments on the template.
First you need to specify the ';'. Which is not very need but okay.

I would like to hear your comments on a better way to provide this
functionality. Would it be better as a merge file?

Post by l***@ikke.net
The second is that the template produces a java file that is incorrect.

This was fixed in CVS a while back but has not been released yet.
Ben
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user