hibernate-devel — development

[Hibernate] XML Mapping Option: class prefix

[Donnerstag, J. <jue...@ed...>]

I'm fairly new to hibernate. Please apologize if this is silly =
question.

I have several XML mapping files, one for each table. Each mapping file
contains several locations where fully qualified class names are =
required.

Like hibernate.query.imports is there a way to define the package, or =
at
least some common root package which is used as a common prefix. I =
wouldn't
have to type in the fully qualified class name over and over again. =
Besides
it makes it easier to modify and more flexible. I could imagine a =
hibernate
property as default location and <hibernate-mapping> and <class> as
redefinition in case it is needed.

regards
J=FCrgen

RE: [Hibernate] Using hibernate - best practices

[Ampie B. <amp...@mw...>]

I like the services-layer idea, but also have to agree that it leads to
repetitive code.

In our system, we have implemented the service layer as session beans. The
transaction management is taken care of by the container. But we still have
the repititive
try{
opensession();
}catch(Exception e){
rolbackSession();throw e;
}finally{
closession();
}
I have also simply sacrificed session propagation from one session bean to
another.

If someone were to implement  the sessionFactory as a JCA connector, all of
this code would become the responsibility of the container. It would also do
the propagation of transaction contexts.

As an interim solution, someone could perhaps implement a "stateless"
version of the session factory that automatically flushes and closes itself
when a transaction commits, and closes when the transaction rolls back.

Am I on the right track here?


-----Original Message-----
From: hib...@li...
[mailto:hib...@li...]On Behalf Of Jozsa
Kristof
Sent: 15 November 2002 01:02
To: Urberg, John
Cc: hib...@li...
Subject: Re: [Hibernate] Using hibernate - best practices


On Thu, Nov 14, 2002 at 01:36:13PM -0600, Urberg, John wrote:
..
> The InvoiceRepository would be implemented like this:
>
>      public class HibernateInvoiceRepository {
>         public void setDatabase(Database database) { _database =
> (HibernateDatabase) database; }
>         public List getOverdueInvoices() {
>              return database.getSession().find("<hibernate query>");
>         }
>         public void update(Object object) {
>               database.getSession().saveOrUpdate(object);
>         }
>     }
>

And where do you close those opened sessions using this design? Also, where
did you find a place to implement transaction handling, including joining
into existing transactions if possible?

I have my own pieces of ideas how to implement a design for Hibernate, but
I'm fighting with the questions listed above too. Got some workaround, but
kinda far from being perfect.. Mainly I used Ralf's third possible solution
from these:

> > *	Put everything into the domain classes.
> > *	Implement something like a "Home" interface
> > *	Implement some sort of component-like / "Service" interface

..having a layer of 'service-like' components in charge of database-related
operations, which either use Hibernate (98%) or plain JDBC pulling the
connection from a Hibernate session. These components are always pulled by
the upper layer from a plain component pool, which I implemented myself. But
mentioning one returning problem, I have *LOTS* of repeated code parts like
these:

Session session = null;
Transaction tx = null;
try {
	session = Hibernator.getSession(); // my custom class which keeps
the sessions and initializes Hibernate
	tx = session.beginTransaction();
	..
	..
	tx.commit();
} catch (Exception e) {
	logger.error (<blah/>), e);
	tx.rollback();
	// rethrow business-exception if suitable
} finally {
	if (session != null) session.close();
}

These piece of codes are repeating in almost ALL of the Service classes'
business methods, are just flooding all the logic badly :( (ok, tx handling
is missing from this where i'm doing read-only operations, but still..) I
also have some part-solution related to joining to existing transactions,
but I find it snappy too.

So, as I said, I don't feel my design good at all.. just couldn't find out
any better for the moment. Therefore, I'd be very happy and thankful to read
about others experiences and concrete architecture/design plans.

Regards,
dyn
--
.Digital.Yearning.for.Networked.Assassination.and.Xenocide


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
hibernate-devel mailing list
hib...@li...
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] Using hibernate - best practices

[Jozsa K. <dy...@on...>]

On Thu, Nov 14, 2002 at 01:36:13PM -0600, Urberg, John wrote:
..
> The InvoiceRepository would be implemented like this:
>     
>      public class HibernateInvoiceRepository {
>         public void setDatabase(Database database) { _database =
> (HibernateDatabase) database; }
>         public List getOverdueInvoices() {
>              return database.getSession().find("<hibernate query>");
>         }
>         public void update(Object object) {
>               database.getSession().saveOrUpdate(object);
>         }
>     }
> 

And where do you close those opened sessions using this design? Also, where
did you find a place to implement transaction handling, including joining
into existing transactions if possible?

I have my own pieces of ideas how to implement a design for Hibernate, but
I'm fighting with the questions listed above too. Got some workaround, but
kinda far from being perfect.. Mainly I used Ralf's third possible solution
from these:

> > *	Put everything into the domain classes.
> > *	Implement something like a "Home" interface
> > *	Implement some sort of component-like / "Service" interface

..having a layer of 'service-like' components in charge of database-related
operations, which either use Hibernate (98%) or plain JDBC pulling the
connection from a Hibernate session. These components are always pulled by
the upper layer from a plain component pool, which I implemented myself. But
mentioning one returning problem, I have *LOTS* of repeated code parts like
these:

Session session = null;
Transaction tx = null;
try {
	session = Hibernator.getSession(); // my custom class which keeps
the sessions and initializes Hibernate
	tx = session.beginTransaction();
	..
	..
	tx.commit();
} catch (Exception e) {
	logger.error (<blah/>), e);
	tx.rollback();
	// rethrow business-exception if suitable
} finally {
	if (session != null) session.close();
}

These piece of codes are repeating in almost ALL of the Service classes'
business methods, are just flooding all the logic badly :( (ok, tx handling
is missing from this where i'm doing read-only operations, but still..) I
also have some part-solution related to joining to existing transactions,
but I find it snappy too.

So, as I said, I don't feel my design good at all.. just couldn't find out
any better for the moment. Therefore, I'd be very happy and thankful to read
about others experiences and concrete architecture/design plans.

Regards,
dyn
-- 
.Digital.Yearning.for.Networked.Assassination.and.Xenocide

RE: [Hibernate] Using hibernate - best practices

[Urberg, J. <ju...@ve...>]

Ralf,

This is what I have done:

1) Created a Database interface that has common database stuff like connect,
commit, rollback, lookup, update, delete, etc.
2) Created "Repository" interfaces that have any database functionality for
a specific domain object or group of domain objects (I got this idea from
http://www.domainlanguage.com/).  If you want to be really safe, you should
put the update and delete in the repository too.
3) Created implementations of database and repository interfaces using
Hibernate.

Example: Lets say I have an Invoice object that contains InvoiceLine
objects.  I have a requirement to load overdue invoices and do something to
them.  I would end up with code like this:

     InvoiceRepository repository =
database.getRepository(InvoiceRepository.class);
     List overdueInvoices = repository.getOverdueInvoices();  // gets
invoices and associated objects
     database.beginTrans();
     for (Iterator i = overdueInvoices.iterator(); i.hasNext(); ) {
          Invoice invoice = (Invoice) i.next();
          invoice.doSomething();
          repository.update(invoice);
     }
     database.commit();

The InvoiceRepository would be implemented like this:
    
     public class HibernateInvoiceRepository {
        public void setDatabase(Database database) { _database =
(HibernateDatabase) database; }
        public List getOverdueInvoices() {
             return database.getSession().find("<hibernate query>");
        }
        public void update(Object object) {
              database.getSession().saveOrUpdate(object);
        }
    }

Then later, if you need to change your application to work against a
database not supported by Hibernate, you could implement repositories
against it.

Hope this helps,
John
 

>  -----Original Message-----
> From: 	Ralf E. Stranzenbach [mailto:mo...@re...] 
> Sent:	Thursday, November 14, 2002 12:53 PM
> To:	hib...@li...
> Cc:	mh...@be...; Ralf Stranzenbach Edmund
> Subject:	[Hibernate] Using hibernate - best practices
> 
> Hi,
> 
> at the moment i spent some time on a small application using hibernate.
> I've did most of the domain's modeling and implementation. Now i have to
> decide where to place the database (say hibernate) dependent code.
> 
> *	Put everything into the domain classes.
> *	Implement something like a "Home" interface
> *	Implement some sort of component-like / "Service" interface
> 
> Domain Classes with database access
> This implementation strategy seems to be the simplest one of all. Database
> access is at most implemented as static methods of the domain class. But
> unfortunately this establishes a very strong link between the domain
> classes and the persistence provider. If i decide to change the
> persistence provider for any reason, i have to modify all domain classes.
> 
> Implementation of a Home-Interface
> This solution seems to keep things moderate simple. Each domain class
> (e.g. Actor) owns one associated "home interface" (e.g. ActorHome). Using
> some Factory it is possible to obtain a specific implementation (e.g.
> ActorHomeHibernateImpl) of that interface. All communication with the
> underlying persistence provider is channeled through this interface. The
> domain classes will be (almost) free of code dealing with the database
> (Lifecycle etc. seems to be still a problem). In this case i have to
> provide some abstraction for the persistence services (update(), delete(),
> TX-management).
> 
> Implementation of Service like structures
> This is more or less the same idea like above but with coarser
> granularity. In this case i think about interfaces covering note single
> domain classes but semantic groups of them. In this way something that
> smells like a "component" (with its own lifecycle) could be implemented.
> Using this strategy the Service-Interface would behave also as a service
> provider for the domain classes. But this design could offer some chances
> to reimplement parts of the application using different persistence
> providers (requires the domain classes using the Service-Interface if
> crossing "component" borders).
> 
> At this moment i'm not sure wich basic design i should use. Please drop me
> some notes about this topic.
> *	Which is your preffered strategy?
> *	Why have you choosen your way?
> *	What are the benefits or the drawbacks?
> 
> regards,
> Ralf E. Stranzenbach

[Hibernate] Using hibernate - best practices

[Ralf E. S. <mo...@re...>]

Hi,

at the moment i spent some time on a small application using hibernate. I've
did most of the domain's modeling and implementation. Now i have to decide
where to place the database (say hibernate) dependent code.

*	Put everything into the domain classes.
*	Implement something like a "Home" interface
*	Implement some sort of component-like / "Service" interface

Domain Classes with database access
This implementation strategy seems to be the simplest one of all. Database
access is at most implemented as static methods of the domain class. But
unfortunately this establishes a very strong link between the domain classes
and the persistence provider. If i decide to change the persistence provider
for any reason, i have to modify all domain classes.

Implementation of a Home-Interface
This solution seems to keep things moderate simple. Each domain class (e.g.
Actor) owns one associated "home interface" (e.g. ActorHome). Using some
Factory it is possible to obtain a specific implementation (e.g.
ActorHomeHibernateImpl) of that interface. All communication with the
underlying persistence provider is channeled through this interface. The
domain classes will be (almost) free of code dealing with the database
(Lifecycle etc. seems to be still a problem). In this case i have to provide
some abstraction for the persistence services (update(), delete(),
TX-management).

Implementation of Service like structures
This is more or less the same idea like above but with coarser granularity.
In this case i think about interfaces covering note single domain classes
but semantic groups of them. In this way something that smells like a
"component" (with its own lifecycle) could be implemented. Using this
strategy the Service-Interface would behave also as a service provider for
the domain classes. But this design could offer some chances to reimplement
parts of the application using different persistence providers (requires the
domain classes using the Service-Interface if crossing "component" borders).

At this moment i'm not sure wich basic design i should use. Please drop me
some notes about this topic.
*	Which is your preffered strategy?
*	Why have you choosen your way?
*	What are the benefits or the drawbacks?

regards,
Ralf E. Stranzenbach

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Gavin K. <ga...@ap...>]

Theres a couple of considerations:

* When theres a large number of persistent classes, a single mapping
document becomes way to large, unmanageable and virtually impossible to
navigate. ie. the same reason why we don't define all our Java classes in
one big file. Plus, it keeps the mapping right there in the same directory
as the mapped class - easy to find and manage. I have had bad experiences
with things like the monolithic struts-config.xml

* In a team environment, multiple files tends to interact much better with
version control systems (not so much in the case of CVS, but certainly with
envy or any system based on locking).


Gavin


----- Original Message -----
From: "Andrea Aime" <aa...@li...>
To: "Gavin King" <ga...@ap...>; "Daniel Bradby"
<db...@bi...>; <hib...@li...>
Sent: Sunday, November 10, 2002 2:41 AM
Subject: Re: [Hibernate] Tom Cellucci's database reverse engineering tool


> On Friday 08 November 2002 23:48, Gavin King wrote:
> > > Can we move towards the "best practise" of having one mapping per
class
> > > maybe?
> >
> > Yeah, I already requested that (theres a thread in the forum).
> >
>
> But why is a best practice? One file per class requires, say, ten open
editors
> to have a look at the whole mapping (A refers a B class, what is it?...
> we'll, let's open B.hbm.xml) and moreover you have more code to write...
> Frankly I just see disadvantages in having more than a single mapping
file...
> Best regards
> Andrea Aime
>
>
> -------------------------------------------------------
> 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

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Gavin K. <ga...@ap...>]

> I think you can spell both the verb and the noun with 's' or 'c'

Thanks for clearing that up :)

I was playing with your SchemaUpdater today (getting it working as a
commandline tool). I made a change to get it working with DB2 that I'm not
too happy about: I had to change the schema name to "%" instead of the
userName. Anyway, have a look and tell me if you can think of any better
idea.

Gavin

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Christoph S. <ch...@mc...>]

Hey Gavin!
----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Daniel Bradby" <db...@bi...>;
<hib...@li...>
Sent: Saturday, November 09, 2002 12:48 AM
Subject: Re: [Hibernate] Tom Cellucci's database reverse engineering tool


>
> > Can we move towards the "best practise" of having one mapping per class
> > maybe?
>
> Yeah, I already requested that (theres a thread in the forum).
>
> P.S. Do I spell practice right? Should it be a 'c' or an 's'? I don't care
> about US-style spelling or whatever, but there are two words, right, a
verb
> and a noun. Am I spelling the noun like the verb?

I think you can spell both the verb and the noun with 's' or 'c'
see http://www.m-w.com


regards
 chris
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Andrea A. <aa...@li...>]

On Friday 08 November 2002 23:48, Gavin King wrote:
> > Can we move towards the "best practise" of having one mapping per class
> > maybe?
>
> Yeah, I already requested that (theres a thread in the forum).
>

But why is a best practice? One file per class requires, say, ten open editors 
to have a look at the whole mapping (A refers a B class, what is it?... 
we'll, let's open B.hbm.xml) and moreover you have more code to write...
Frankly I just see disadvantages in having more than a single mapping file...
Best regards
Andrea Aime

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Gavin K. <ga...@ap...>]

> Can we move towards the "best practise" of having one mapping per class
> maybe?

Yeah, I already requested that (theres a thread in the forum).

P.S. Do I spell practice right? Should it be a 'c' or an 's'? I don't care
about US-style spelling or whatever, but there are two words, right, a verb
and a noun. Am I spelling the noun like the verb?

Re: [Hibernate] Patch to CodeGenerator (BasicRenderer.java)

[Gavin K. <ga...@ap...>]

Thanks!

I checked it into CVS.

peace :)

----- Original Message ----- 
From: "Aapo Laakkonen" <aap...@gi...>
To: <hib...@li...>
Sent: Saturday, November 09, 2002 2:59 AM
Subject: [Hibernate] Patch to CodeGenerator (BasicRenderer.java)


> Here is the patch I promised to make to BasicRenderer.java that is
> related to CodeGenerator tool. This patch provides boolean getters eg.:
> 
>     public boolean isSomething() {
>         return this.something;
>     }
> 
> Instead of:
> 
>     public boolean getSomething() {
>         return this.something;
>     }
> 
> Just a quick patch, and as someone noted the CodeGenerator should be
> rewritten so that it takes advantage of common mapping file parsing
> routine to keep utility in sync with Hibernate.
> 
> Note: This patch does not include one-to-one mapping support, just the
> boolean getter support.
> 
> Regards
> Aapo Laakkonen
> 

Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Daniel B. <db...@bi...>]

Awesome! I just pointed it at a MySQL database I had here and it worked 
great. Can't wait to see it cleaned up and put into CVS

I might try it against some more complex schema at work next week.

Can we move towards the "best practise" of having one mapping per class 
maybe?

Gavin King wrote:

>Has everyone seen this:
>
>http://66.218.140.50/tac/index.html
>
>Its a tool to reverse engineer Hibernate mapping documents from the
>database. Very nice (and a nice Swing UI.)
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: See the NEW Palm 
>Tungsten T handheld. Power & Color in a compact size!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>_______________________________________________
>hibernate-devel mailing list
>hib...@li...
>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>  
>

[Hibernate] Patch to CodeGenerator (BasicRenderer.java)

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

Here is the patch I promised to make to BasicRenderer.java that is
related to CodeGenerator tool. This patch provides boolean getters eg.:

    public boolean isSomething() {
        return this.something;
    }

Instead of:

    public boolean getSomething() {
        return this.something;
    }

Just a quick patch, and as someone noted the CodeGenerator should be
rewritten so that it takes advantage of common mapping file parsing
routine to keep utility in sync with Hibernate.

Note: This patch does not include one-to-one mapping support, just the
boolean getter support.

Regards
Aapo Laakkonen

[Hibernate] Tom Cellucci's database reverse engineering tool

[Gavin K. <ga...@ap...>]

Has everyone seen this:

http://66.218.140.50/tac/index.html

Its a tool to reverse engineer Hibernate mapping documents from the
database. Very nice (and a nice Swing UI.)

Re: [Hibernate] XDoclet Hibernate subtasks

[Gavin K. <ga...@ap...>]

> Ara is himself here to help :-)

Excellent!

> I'm involved in a project that probably (90%) will use Hibernate. So
> I'll have to use it myself and be sure I can't resist contributing to
> open source projects :-) So wherever the module ends up in I'll
> contribute. I think it's better for it to live in hibernate's cvs.

Even excellenter :)

> Btw, as described previously in xdoclet-devel we'll probably set up a
> smart distributed module build system using Maven in xdoclet2. So you'll
> host the module in hibernate's cvs, but we'll checkout it, build it and
> bundle it and even test it. This way we'll be able to keep an eye on
> what's going on in remotely hosted modules and still keep it separated.

Great, sounds like a solution that keeps everyone happy. (PS. I'm very 
impressed with the whole "Maven distributed module build system".)


peace

Gavin

RE: [Hibernate] XDoclet Hibernate subtasks

[Ara A. <ar...@ya...>]

> > I remember that you (Gavin) mentioned that the Xdoclet team would
take
> > over the Hibernate task. Is that going to happen? I see some project
> > branching going on there towards some Jakarta templates too.
> 
> Ara will accept the Hibernate module into their codebase but we would
need
> to maintain it ourselves with *no* CVS access (at least initially). I
> would
> much prefer it to live in their CVS repository but I am unwilling to
> maintain the code myself using patches. I am very keen for this code
to
> find
> itself an "owner" since I have enough on my plate with the persistence
> engine. The rest of our toolset was created and is being mainly
maintained
> by other people and I would like to see the same happen here.

Ara is himself here to help :-)

I'm involved in a project that probably (90%) will use Hibernate. So
I'll have to use it myself and be sure I can't resist contributing to
open source projects :-) So wherever the module ends up in I'll
contribute. I think it's better for it to live in hibernate's cvs.

Btw, as described previously in xdoclet-devel we'll probably set up a
smart distributed module build system using Maven in xdoclet2. So you'll
host the module in hibernate's cvs, but we'll checkout it, build it and
bundle it and even test it. This way we'll be able to keep an eye on
what's going on in remotely hosted modules and still keep it separated.

Ara.

Re: [Hibernate] XDoclet Hibernate subtasks

[Gavin K. <ga...@ap...>]

Hi Daniel, how's everyone :-)


> I actually gave it a whirl against the latest XDoclet release (1.2.0
> beta 1 ) and it generates the mapping file no worries.

Oh does it? Cool ... it was broken against a CVS snapshot I tried but
perhaps that was just a broken snapshot.....

> From my initial
> glance it looked fine as well. I also tried it against a build from
> latest CVS. It was also fine, although it did generate some warning
> messages. I'll actually try the mapping file out though. Was there any
> known specific issues?

The mapping document was specifically not generated ;)

Another issue is that the module should be updated to reflect our latest DTD
(hibernate-mapping-1.1.dtd) which is not a big job, I'm certain.

> I remember that you (Gavin) mentioned that the Xdoclet team would take
> over the Hibernate task. Is that going to happen? I see some project
> branching going on there towards some Jakarta templates too.

Ara will accept the Hibernate module into their codebase but we would need
to maintain it ourselves with *no* CVS access (at least initially). I would
much prefer it to live in their CVS repository but I am unwilling to
maintain the code myself using patches. I am very keen for this code to find
itself an "owner" since I have enough on my plate with the persistence
engine. The rest of our toolset was created and is being mainly maintained
by other people and I would like to see the same happen here.

Gavin

Re: [Hibernate] Eclipse plugin for Hibernate

[Jozsa K. <dy...@on...>]

Go ahead, that's why I posted the link to the current source.. :)

Christopher

On Fri, Nov 08, 2002 at 09:44:20PM +1100, Daniel Bradby wrote:
> 
> I have recently skilled up on Eclipse 2 plugin and SWT architecture 
> (playing with a Subversion plugin) . Maybe I could have a look at it to 
> see I can get my head around it?
> 
> 
> 
> Jozsa Kristof wrote:
> 
> >Hi there,
> >
> >I wonder if anyone's interested in the development of an Eclipse plugin for
> >Hibernate. A couple of weeks ago I sketched the base of such a plugin, which
> >is able to generate the skeleton of a mapping file for the class opened in
> >the active editor window. I've discussed quickly with Gavin at that time,
> >and he basically doubled its functionality, so it detects now relations
> >too.. I promised I'll develop the code further, but now I clearly turned
> >out, that I don't have the time for doing further development on that plugin
> >:( It's particularly useful even in its current state, but sure it could
> >sport many more features. (We do have ONE known bug too, which needs to be
> >fixed :)
> >
> >I do that announcement (or whatever you call it) cos I already passed the
> >code for a couple of people, who requested it on irc, and they did find it
> >quite useful.. but it cannot be released without a maintainer, who really
> >cares about it, and who has some free time which can be donated to this
> >development - and unfortunately I cannot afford this atm :(
> >
> >So, if anyone is interested in developing that plugin, I'd love to give the
> >code over to a new maintainer.. 
> >
> >It'd also be discussed, whether we should stay on Eclipse's reflection
> >classes on class' property detection, or rather should drop that, and move
> >to the track used by the current command line tools..
> >
> >
> >An old screenshot of the plugin in action can be seen at (check the right
> >side of the shot): 
> >http://ond.vein.hu/~dyn/hibernator.png
> >
> >The current snapshot (Gavin's version) can be found at:
> >http://ond.vein.hu/~dyn/hibernator-gk.tar.gz
> >
> >
> >Regards,
> >Christopher
> >  
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

-- 
.Digital.Yearning.for.Networked.Assassination.and.Xenocide

Re: [Hibernate] Eclipse plugin for Hibernate

[Daniel B. <db...@bi...>]

I have recently skilled up on Eclipse 2 plugin and SWT architecture 
(playing with a Subversion plugin) . Maybe I could have a look at it to 
see I can get my head around it?



Jozsa Kristof wrote:

>Hi there,
>
>I wonder if anyone's interested in the development of an Eclipse plugin for
>Hibernate. A couple of weeks ago I sketched the base of such a plugin, which
>is able to generate the skeleton of a mapping file for the class opened in
>the active editor window. I've discussed quickly with Gavin at that time,
>and he basically doubled its functionality, so it detects now relations
>too.. I promised I'll develop the code further, but now I clearly turned
>out, that I don't have the time for doing further development on that plugin
>:( It's particularly useful even in its current state, but sure it could
>sport many more features. (We do have ONE known bug too, which needs to be
>fixed :)
>
>I do that announcement (or whatever you call it) cos I already passed the
>code for a couple of people, who requested it on irc, and they did find it
>quite useful.. but it cannot be released without a maintainer, who really
>cares about it, and who has some free time which can be donated to this
>development - and unfortunately I cannot afford this atm :(
>
>So, if anyone is interested in developing that plugin, I'd love to give the
>code over to a new maintainer.. 
>
>It'd also be discussed, whether we should stay on Eclipse's reflection
>classes on class' property detection, or rather should drop that, and move
>to the track used by the current command line tools..
>
>
>An old screenshot of the plugin in action can be seen at (check the right
>side of the shot): 
>http://ond.vein.hu/~dyn/hibernator.png
>
>The current snapshot (Gavin's version) can be found at:
>http://ond.vein.hu/~dyn/hibernator-gk.tar.gz
>
>
>Regards,
>Christopher
>  
>

Re: [Hibernate] XDoclet Hibernate subtasks

[Daniel B. <db...@bi...>]

I actually gave it a whirl against the latest XDoclet release (1.2.0 
beta 1 ) and it generates the mapping file no worries. From my initial 
glance it looked fine as well. I also tried it against a build from 
latest CVS. It was also fine, although it did generate some warning 
messages. I'll actually try the mapping file out though. Was there any 
known specific issues?

I remember that you (Gavin) mentioned that the Xdoclet team would take 
over the Hibernate task. Is that going to happen? I see some project 
branching going on there towards some Jakarta templates too.

Hmmmm any thoughts?

Gavin King wrote:

>It already exists in CVS (The "Tools" module). This was written by Sebastien
>Guimont but is currently kinda ownerless....
>
>Its probably *not* working against the latest release of XDoclet though. I
>would very much appreciate if someone would get it working against their
>latest release.
>
>----- Original Message -----
>From: "Danilo Luiz Rheinheimer" <da...@fl...>
>To: <hib...@li...>
>Sent: Friday, November 08, 2002 12:04 PM
>Subject: [Hibernate] XDoclet Hibernate subtasks
>
>
>  
>
>>Hello,
>>
>>  Someone is working on a XDoclet subtask to hibernate ?
>>
>>--
>>Best regards,
>> Danilo                          mailto:da...@fl...
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: See the NEW Palm
>>Tungsten T handheld. Power & Color in a compact size!
>>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>>_______________________________________________
>>hibernate-devel mailing list
>>hib...@li...
>>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>    
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: See the NEW Palm 
>Tungsten T handheld. Power & Color in a compact size!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>_______________________________________________
>hibernate-devel mailing list
>hib...@li...
>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>  
>

[Hibernate] Eclipse plugin for Hibernate

[Jozsa K. <dy...@on...>]

Hi there,

I wonder if anyone's interested in the development of an Eclipse plugin for
Hibernate. A couple of weeks ago I sketched the base of such a plugin, which
is able to generate the skeleton of a mapping file for the class opened in
the active editor window. I've discussed quickly with Gavin at that time,
and he basically doubled its functionality, so it detects now relations
too.. I promised I'll develop the code further, but now I clearly turned
out, that I don't have the time for doing further development on that plugin
:( It's particularly useful even in its current state, but sure it could
sport many more features. (We do have ONE known bug too, which needs to be
fixed :)

I do that announcement (or whatever you call it) cos I already passed the
code for a couple of people, who requested it on irc, and they did find it
quite useful.. but it cannot be released without a maintainer, who really
cares about it, and who has some free time which can be donated to this
development - and unfortunately I cannot afford this atm :(

So, if anyone is interested in developing that plugin, I'd love to give the
code over to a new maintainer.. 

It'd also be discussed, whether we should stay on Eclipse's reflection
classes on class' property detection, or rather should drop that, and move
to the track used by the current command line tools..


An old screenshot of the plugin in action can be seen at (check the right
side of the shot): 
http://ond.vein.hu/~dyn/hibernator.png

The current snapshot (Gavin's version) can be found at:
http://ond.vein.hu/~dyn/hibernator-gk.tar.gz


Regards,
Christopher
-- 
.Digital.Yearning.for.Networked.Assassination.and.Xenocide

Re: [Hibernate] CodeGenerator

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

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

And sadly it is more than just <one-to-one> that is ignored - and one of the
primary reasons
is that the CodeGenerator is doing it is own parsing of the hbm.xml files
thus it is not
at all in sync with the changes that have been going on regarding the dtd
and new stuff
that has changed semantics/syntax of the different tags :(

That is why i've been searching for a way to have a "unified" parsing of
hbm.xml into some
metadata structure that does not realy on the referred classes to be
available on the classpath -
that would make the codegenerator, the mapping tool etc. much more in sync
with the core
hibernate engine.

just my 3 cents
/max


> ----- Original Message -----
> From: "Aapo Laakkonen" <aap...@pr...>
> To: <hib...@li...>
> Sent: Friday, November 08, 2002 12:54 AM
> Subject: [Hibernate] CodeGenerator
>
>
> > Is it possible to modify CodeGenerator tool so that when I have property
> > type set to "true_false" or "yes_no" and name set to "something" eg.:
> >
> > <property name="something" column="something" type="true_false"
> > not-null="true" unique="false"/>
> >
> > to generate something like this:
> >
> >     public boolean isSomething() {
> >         return this.something;
> >     }
> >
> >     public void setSomething(boolean something) {
> >         this.something = something;
> >     }
> >
> > Currently it generates getter eg.:
> >
> >     public boolean getSomething() {
> >         return this.something;
> >     }
> >
> > Kind Regards
> > Aapo Laakkonen
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: See the NEW Palm
> > Tungsten T handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> > _______________________________________________
> > hibernate-devel mailing list
> > hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/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] Components without public no-arg constructor

[Gavin K. <ga...@ap...>]

Ah. Interesting. If I wouldn't have just checked the code I would have
thought a private noarg constructor was allowed for components also - but
you are quite correct; ComponentType uses Class.newInstance() to instantiate
components. You wanna make a patch, John? (Probably refactor the code for
this out of the persister package and onto ReflectHelper...)

peace

Gavin

----- Original Message -----
From: "Urberg, John" <ju...@ve...>
To: <hib...@li...>
Sent: Friday, November 08, 2002 7:07 AM
Subject: [Hibernate] Components without public no-arg constructor


> I notice we can now map classes that don't have public no-arg
constructors.
> Is it possible to extend that to components also?
>
> Many of the components I use will be value objects and I'd like to make
them
> immutable (including composite ids).  I could do this if Hibernate could
use
> a private no arg constructor.
>
> Thanks,
> John
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] CodeGenerator

[Gavin K. <ga...@ap...>]

Yeah that would make more sense. Do you wanna produce a patch?

(Do we need to worry about backward compatibility on this?)

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

----- Original Message -----
From: "Aapo Laakkonen" <aap...@pr...>
To: <hib...@li...>
Sent: Friday, November 08, 2002 12:54 AM
Subject: [Hibernate] CodeGenerator


> Is it possible to modify CodeGenerator tool so that when I have property
> type set to "true_false" or "yes_no" and name set to "something" eg.:
>
> <property name="something" column="something" type="true_false"
> not-null="true" unique="false"/>
>
> to generate something like this:
>
>     public boolean isSomething() {
>         return this.something;
>     }
>
>     public void setSomething(boolean something) {
>         this.something = something;
>     }
>
> Currently it generates getter eg.:
>
>     public boolean getSomething() {
>         return this.something;
>     }
>
> Kind Regards
> Aapo Laakkonen
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel