-->
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.  [ 6 posts ] 
Author Message
 Post subject: Let Hibernate generate tables ?
PostPosted: Wed Jun 28, 2006 1:24 am 
Newbie

Joined: Wed Jun 28, 2006 1:03 am
Posts: 14
Hi all,

I am ok with database design…

But most of the hibernate tutorials and books that I read design the Java classes and let Hibernate create the DB tables and all.

I have already hand-crafted my DB design and all the tables in MySQL. I am not sure whether to throw all that away and let Hibernate generate all tables from java classes.

I am currently starting to map Java classes to my existing DB design/tables. Manually mapping Java’s “short” to MySQL’s “smallint” … for example.

I have a lot of tables. Please advice.

Thanks.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 28, 2006 1:43 am 
Expert
Expert

Joined: Thu Dec 23, 2004 9:08 pm
Posts: 2008
Don't throw anything away: hibernate is about making your life easier, not harder. Plus, you learn more, faster by using an existing schema: you are going to get loads of mapping errors, constraint violations, etc., all of which will cause you to investigate the ins and outs of mapping properly, resulting in better mappings in your app and a better understanding of hibernate for you.

_________________
Code tags are your friend. Know them and use them.


Top
 Profile  
 
 Post subject: What kind of automation should I go for ?
PostPosted: Wed Jun 28, 2006 4:26 am 
Newbie

Joined: Wed Jun 28, 2006 1:03 am
Posts: 14
Thanks for the reply.

But is it better to let Hibernate generate all things on the DB side from Java Domain classes ? Will this cause less problems ? Is this a better way since Hibernate knows best how the DB should match the Java classes ?

I am currently hand-crafting my DB schemas, writing my Java classes and writing the hbm.xml mapping files ... all manually. I am just worried that development will get tougher as development go towards production... as the system becomes more complex.

If there is really a better way (less trouble) of doing things that need me to throw my hand-made DB schema away now... although it will be a waste but I am willing dump it for the sake of experiencing faster development as development progresses.

Pls advice.

Thanks again.


Top
 Profile  
 
 Post subject: The best way to go forward.
PostPosted: Wed Jun 28, 2006 4:30 am 
Newbie

Joined: Wed Jun 28, 2006 1:03 am
Posts: 14
Hi ... I just feel very venerable as just a simple hbm2ddl set to "update"/"create"/"create-drop" and my hand-coded DB DDL codes (tables/foreign key reference integrity etc) will be wiped off and re-written by Hibernate.

I need to know what is the best way to go forward.


Top
 Profile  
 
 Post subject: "validate" and only "validate" ?
PostPosted: Wed Jun 28, 2006 4:33 am 
Newbie

Joined: Wed Jun 28, 2006 1:03 am
Posts: 14
In my case, if...if I want to preserve what I have coded in my DB side... my hbm2ddl has to be set to "validate" and only "validate" ?

Is this a good way to proceed with the development ?

Pls advice. Thanks.


Top
 Profile  
 
 Post subject: "validate" and "update" for hbm2ddl.auto
PostPosted: Wed Jun 28, 2006 5:02 am 
Newbie

Joined: Wed Jun 28, 2006 1:03 am
Posts: 14
Actually...I am rather confused between "validate" and "update" for hbm2ddl.auto.

Can someone explain the difference to me ?

Thanks.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 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.