-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 
Author Message
 Post subject: Choosing code-generation tool
PostPosted: Thu Sep 11, 2003 9:39 am 
Newbie

Joined: Mon Sep 08, 2003 12:16 am
Posts: 9
I'm trying to decide on a code-generation tool to build my persistent classes. I've tried hbm2java and xdoclet, and both seem to work great.

Are there advantages/disadvantages to using java->hbm vs. the hbm->java?

Additionally, my app uses a stored procedure persister, so I need to write 2 extra classes for each persistent class (one to massage the data from hibernate before calling one to run the stored procedure).

I'd like those 2 classes to be auto-generated as well. Would hbm2java or Xdoclet let me do this, or are there other tools out there that I might be able to write a Velocity template or something?

Finally... are there any tools to parse an Oracle stored procedure and create the java or hbm (depending on which other tools were used..)? It doesn't seem like this would be too hard to write. I mean this part, not sure what it's actually called:

PROCEDURE del_user_addresses (
txn_id_in IN VARCHAR2,
user_address_id_in IN VARCHAR2,
subtxn_id_inout IN OUT VARCHAR2
);


Just looking for some experienced advice, as I am fairly new to the Java world.

Thanks,
- Ryan


Top
 Profile  
 
 Post subject: Re: Choosing code-generation tool
PostPosted: Thu Sep 11, 2003 9:56 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
[quote="rcarver"]
Are there advantages/disadvantages to using java->hbm vs. the hbm->java?
[/qoute]

It all depends on your development method....

Are you writing java code first, and then hbm.xml...
or are you just as comfortable with defining the hbm.xml first and then have it generate java code ?

[quote]
Additionally, my app uses a stored procedure persister, so I need to write 2 extra classes for each persistent class (one to massage the data from hibernate before calling one to run the stored procedure).
[/qoute]

That sounds "funny" - why is that ? Can you give an example ?

[quote]
I'd like those 2 classes to be auto-generated as well. Would hbm2java or Xdoclet let me do this, or are there other tools out there that I might be able to write a Velocity template or something?
[/qoute]

hbm2java sounds like the tool for the job - at least in my opinion ,)
hbm2java can easily be extended by writing you own Renderer - there already exist atleast 2 examples of generating e.g. Finders and SLSB from the hbm.xml files

- i'm also considering adding a velocity template renderer..but it won't happen just now ;)

[quote]
Finally... are there any tools to parse an Oracle stored procedure and create the java or hbm (depending on which other tools were used..)? It doesn't seem like this would be too hard to write. I mean this part, not sure what it's actually called:

PROCEDURE del_user_addresses (
txn_id_in IN VARCHAR2,
user_address_id_in IN VARCHAR2,
subtxn_id_inout IN OUT VARCHAR2
);
[/qoute]

That sounds like a very very special case that only apply to your project and your own stored procedure persister :)
So, that I think you should write your self.

But it would be nice to hear about and see your stored procedure persisters - especially to discover how hibernate might be extended to better support stored procedures

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 10:52 am 
Newbie

Joined: Mon Sep 08, 2003 12:16 am
Posts: 9
Quote:
Are you writing java code first, and then hbm.xml...
or are you just as comfortable with defining the hbm.xml first and then have it generate java code ?


I'm comfortable either way. My only concern was if I needed to add methods to the class, something like:
addFoo(foo) { foos.add(foo); foo.setParent(this); }

then I wouldn't want to regenerate and lose that, but it seems like you could sub-class the generated class to add functionality.

------------

Let me backup and explain what I'm working with here. Any suggestions are welcome, like I said I'm new to java (and stored procedures!) and kind of figuring this out as I go.

I'm working with an Oracle guy who is building the database and prefers to use stored procedures for all insert/update/delete operations so he can perform other tasks behind the scenes (logging, auditing, etc). Also, most of the business logic, calculations will happen on the database side.

What I was hoping to do is parse that PROCEDURE definition into an .hbm file, then use hbm2java to build the persistent class and other classes. Sounds like hbm2java might do the trick, I'll look into it some more.

------------

Here's a rundown of how my stored procedure persister works. If this is a rediculously stupid hack, I'm all ears for better methods!

1. CustomTransactionFactory returns CustomTransaction
a. CustomTransaction generates a transactionId for this logical set of actions

2. CustomPersister extends EntityPersister, overrides:
insert(Object[] values, Object object, SessionImplementor session)
a. I also use a CustomIdentifierGenerator to return null so that inserts go through this insert method since Id's are generated by the stored procedure.

3. insert() gets the transactionId from the session's transaction and translates the Object array into a Map of value by property name
a. call abstract method: doInsert(transactionId, myPropsMap, session.connection());

4. doInsert is implemented for each persistent type. It extracts the values from the Map and calls MyTypeProcedures.insert(transactionId, [all properties], connection). I did this so that this method doesn't depend at all on Hibernate, it's just a static method that calls a stored procedure with the supplied arguments.

5. MyTypeProcedures.insert creates and executes a CallableStatement, returns the inserted Id

6. doInsert() returns the Id back to insert()

7. insert() returns (Serializable) Id

That's it... I've simplified and left out a few steps here. There's also a subTransactionId that gets passed back with the inserted Id and set on the persistent object (using update="false" in mapping file so that doesn't trigger an update)

Hope that all makes some kind of sense

- Ryan


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 11:09 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
rcarver wrote:
Quote:
Are you writing java code first, and then hbm.xml...
or are you just as comfortable with defining the hbm.xml first and then have it generate java code ?


I'm comfortable either way. My only concern was if I needed to add methods to the class, something like:
addFoo(foo) { foos.add(foo); foo.setParent(this); }

then I wouldn't want to regenerate and lose that, but it seems like you could sub-class the generated class to add functionality.


With hbm2java you should take a look at the meta attribute support and the "generated-class" attribute. It allows for such "stuff" ;)

Quote:
I'm working with an Oracle guy who is building the database and prefers to use stored procedures for all insert/update/delete operations so he can perform other tasks behind the scenes (logging, auditing, etc). Also, most of the business logic, calculations will happen on the database side.


ok - a nightmare in my view, but then again - it's reality ;)

Quote:
What I was hoping to do is parse that PROCEDURE definition into an .hbm file, then use hbm2java to build the persistent class and other classes. Sounds like hbm2java might do the trick, I'll look into it some more.


Just do it ;)

Quote:
Here's a rundown of how my stored procedure persister works. If this is a rediculously stupid hack, I'm all ears for better methods!

That's it... I've simplified and left out a few steps here. There's also a subTransactionId that gets passed back with the inserted Id and set on the persistent object (using update="false" in mapping file so that doesn't trigger an update)


It sounds reasonably for your setup - it would be nice to see the code for the custompersister too.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 11:31 am 
Newbie

Joined: Mon Sep 08, 2003 12:16 am
Posts: 9
Quote:
ok - a nightmare in my view, but then again - it's reality ;)

why is that? I know it kind of goes against the grain, but it seems logical enough to me.. :) Am I doing anything here that could really cause problems later on? I'm satisfied so far because I get to use the stored procedures, plus Hibernate's caching, relational mapping and querying.

One thing I'm wrestling with - for example, he wants to write a procedure to delete a User, which would also delete all related entries. But I can accomplish the same thing through Hibernate with cascading - though with much more sql traffic. Would it cause problems with Hibernate to do it the procedure way?

I understand his problem; not trusting anyone else to manage database state, I just need to figure out where to draw the line.


here's the insert() method from my custom persister:

Code:
public Serializable insert(Object[] values, Object object, SessionImplementor session) throws SQLException, HibernateException {
   
   if (object instanceof Auditable) {
      Long txnId;
      Long subTxnId;
      Long id;
      
      txnId = getTxnId(session);
      logger.info("Insert instance of " + object.getClass().getName());
      
      PersistentProps props = valuesToProps(values);
      
      ProcedureInsertResult result = doInsert(txnId, props, session.connection());

      id       = result.getId();
      subTxnId = result.getSubTxnId();
      
      logger.info("Insert id: " + id);
      logger.info("Insert subTxnId: " + subTxnId);
      
      ((Auditable) object).setSubTxnId(subTxnId);
      
      return (Serializable) id;         
      
   } else {
      String msg = "Trying to persist (insert) a non-Auditable class: " + object.getClass();
      logger.fatal(msg);
      throw new HibernateException(msg);
   }
}



Thanks again,
- Ryan


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 11:56 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
He doesn't need stored procedures for this stuff! Why not just use triggers?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 12:03 pm 
Newbie

Joined: Mon Sep 08, 2003 12:16 am
Posts: 9
Well there's more to it than that - logging, for example. I'm not sure if triggers could accomplish that as well. I really don't know how all of that works, I'm just trying to tie into it with a minimum of conflict.

the same question stands, though - if you used triggers to delete related records, would Hibernate get confused or would it be ok? To make that work, would you set cascade to not delete so the trigger/other internal process could handle it?

- Ryan


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 12:08 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
I'm not really certain, to be honest. It doesn't sound like it would be such a great thing, 'cos Hibernate wouldn't know that the records were gone.

Still, it might work out fine in practice ... probably would ... I dunno, try it.



P.S. You can do logging in a trigger!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 12:20 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
rcarver wrote:
Quote:
ok - a nightmare in my view, but then again - it's reality ;)

why is that? I know it kind of goes against the grain, but it seems logical enough to me.. :) Am I doing anything here that could really cause problems later on? I'm satisfied so far because I get to use the stored procedures, plus Hibernate's caching, relational mapping and querying.


My main "bug" against putting to much logic in SP's is that i don't have tools like Eclipse to do refactoring, searches, etc. AND PSQL is not the worlds most known language .....but as i said, I know such setup exists and that we all have to live with it ;) (but that don't necesarrily mean i won't complain if i get near it ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 12:37 pm 
Newbie

Joined: Mon Sep 08, 2003 12:16 am
Posts: 9
Quote:
My main "bug" against putting to much logic in SP's is that i don't have tools like Eclipse to do refactoring, searches, etc. AND PSQL is not the worlds most known language .....but as i said, I know such setup exists and that we all have to live with it ;) (but that don't necesarrily mean i won't complain if i get near it ;)


cool. I think this will work for us since he's been doing PSQL for longer than I'm been programming at all. And we have a nice split of responsibilities (java,frontend=me, database,serious business logic=him). As far as refactoring, that goes back to why I wanted to generate the source code in the first place.

btw, any thoughts on my persister? Am I missing out on any great Hibernate features this way?

thank so much (again..) It's nice to hear that I'm not getting this completely wrong :)

- Ryan


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 11, 2003 1:21 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
rcarver wrote:

btw, any thoughts on my persister? Am I missing out on any great Hibernate features this way?



If it works for you i think it's fine ;)

You did not show much of the related code, so i can't make a judgement better than that ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.