One of Hibernate's most useful features is the automatic generation of schema manipulation commands. This sample chapter outlines the ways this feature can be used to greatest effect. Will Iverson discusses how to use the update and import abilities with your project.

Read the sample chapter: J2EE Schema Management with Hibernate

The chapter title of "J2EE Schema Management with Hibernate" seems midleading. Chapter describes the DDL generation using Hibernate tools. Nothing directly to do with J2EE.

Hi All,

I am part of a large Data Warehouse / Data Distribution team at a semi-conductor manufacturing company that uses stored procedures and unix scripts exclusively. However, i am also the web-architect for a software company that uses J2EE in its various forms and implementations.

This article relates in that i often wonder what the true benefits are of dynamic schema generation - given the context of the data. For example, when a change needs to happen at a low level in the data warehouse, changing the table itself is rarely the issue - updating it with appropriate data, and keeping downstream data structures in sync is the largest issue. As my java development team gets more implementations, i am curious as to how valuable the hibernate automatic schema generation tool would be for updating the database structure - if more than likely i am going to have to do a lot of manual work to update the data correctly anyways?

I think this is more of an experience issue relating to java controlled environments needing simliar data requirements that more data-context-sensitive environments (like corp DWs) might be most often susceptible too.

Thanks,
~tim

Schema export can be very useful during prototyping and early development, assuming that you're working with a new database.

Rgds
Rod
Spring from the Source

Schema export can be very useful during prototyping and early development, assuming that you're working with a new database.

Sure, and why not thinking at the HBM files like a repository for the datamodel with mappings for the object oriented side and the relational side ?

I have not found schema export on it's own to be that useful, but doing the full life cycle with Hibernate is.

* Code the Java classes with Hibernate XDoclet tags
* Generate the Hibernate schema with XDoclet
* Generate the database DDL with schema export

Will's comment on model driven development is reflected in projects like AndroMDA, where the Java classes can be generated from the UML model with the Hibernate XDoclet tags embedded, and the above process is carried out.

Apparently, there are people who use schema export as part of their applications, but I think most folks use it during development and maintenance. It is useful to know what DB changes need to be made.

Sherman

Sure, and why not thinking at the HBM files like a repository for the datamodel with mappings for the object oriented side and the relational side ?

Yes it is a kind of model too, diagrams, documentation, code, schema can be generated from this model, but is has many implementation details. It is not a problem is developer, DBA and bussiness analyst is the same person, but it is not the case in "complex" projects. Domains are complex, not SQL or frameworks.

+1 , J2EE != hibernate (yet (cmp ))

+1 , J2EE != hibernate (yet (cmp ))

The book has J2EE in the title because the marketing and sales folk felt that it would be easier for the retail buyers and stockers to figure out who the book was for.

I wasn't sure about it until I mentioned to a family member that I was working on a book on Hibernate and they were surprised that I knew anything about "sleep science." :P

As far as the article title, no idea. Here are the areas I've personally found Hibernate schema management useful:

- Apps for resale that are intended to support multiple databases
- Initializing desktop client database systems as part of the app init
- Model-driven development projects in which the Java code can drive the app

Cheers,

-Will

Here are the areas I've personally found Hibernate schema management useful:
- Apps for resale that are intended to support multiple databases
- Initializing desktop client database systems as part of the app init
- Model-driven development projects in which the Java code can drive the app

In "Model-driven projects" Model drives Java code and the app, model doe's not depend on database implementation, Hibernate is more designed and used to develop web applications (install problem doe's not exist for most web applications).
So I do not think this stuff is very useful. Database schema is a kind of model itself and I think the best way to start from conceptual model. There are many ways to design this stuff, but I found ER modeling is very good to work with databases, it is simple and it maps very good to phisical model, this process can be automated. I do not think XML files can replace modeling, if model is important.
I think it is important, databse is used by multiple applications ( information system ) in most of cases, it can be problematic to integrate and maintain applications if one of them drives schema.

Hibernate is more designed and used to develop web applications (install problem doe's not exist for most web applications)

From Hibernates website:

Hibernate is typically used in Java Swing applications, Java Servlet-based applications, or J2EE applications using EJB session beans

And

Hibernate is architecture-agnostic. Because Hibernate provides persistence as a service, rather than as a framework, it integrates seamlessly with various application architectures.

I can be wrong, but I read Hibernate forums and I see most developers work with web applications.

I can be wrong, but I read Hibernate forums and I see most developers work with web applications.

Maybe they are the only ones who need help. :)

I would bet the most comments in Java forums are web related too. It is more of a reflection of the industry and not the tool itself.

I can be wrong, but I read Hibernate forums and I see most developers work with web applications.

Maybe they are the only ones who need help. :)I would bet the most comments in Java forums are web related too. It is more of a reflection of the industry and not the tool itself.

Users drive open source projects, java web aplications are very popular (most of my applications are related to web too) and hibernate is used and driven by web developers. I do not think stuff like cache makes sence in desktop applications or for transaction processing systems. Hibernate is optimized for "read" operations and is designed to scale (it is very important in web).

I would never let a tool such as hibernate manage my database. It may work on small simple projects, but none thae I have seen.

>>"I would never let a tool such as hibernate manage my database. It may work on small simple projects, but none thae I have seen."

<p/>You seem prejudiced since you did not mention any reason why it could not be applied to big projects. I am planning on using Hibernate for a big project and want to know why you say it is not good for big projects.

Go to the Hibernate forums to get opinions on whether Hibernate works for large projects. You will see that some people have problems, but they can be addressed. For my firm, it has been an excellent choice for development (flexibility, productivity, better overall quality than hand coded SQL and entity beans) and production (runs and scales well).

Sherman

I think that the post refers to "hibernate managing the database" i.e. allowing a tool to perform drops and alter on database tables. In a production environment, this could be very risky.

Hibernate works very well for small and large projects. But this is an other, well known story.
/roberto

I would and have used Hibernate on several large projects! I am very impressed with hibernate.

  However, I would never alow Hibernate to generate the schema. On most large projects the schema can not be controlled by an automated process that inspects configuration and code. A lot of thought and desgn must g into the schema. For example, lest say there are some reports that are run in PL-SQL on a nightly basis. How is hibernate going to optimize the schema to allow for there reports to be generated effeciantly???

  Hibernate is great, but don;t get lazy and expect it to do everything for you.

It may work on small simple projects, but none thae I have seen.

Agree.

Check out iBatis( an Apache project), it works great for large projects, SQL and stored procs. I use that instead. It has great and simple auto cacheing, SQL strings are external so DBA can uppdate.... A few memebers on the list used to use Hibreante.

It does have a tool to generate maps based on the data model; but I don't use that.

hth,
.V

Let the FUD begin.

No tool/api/framework is perfect. It takes someone with ability to determine when and where to use what and how.

Just because a tool doesn't work the way you like to work doesn't mean it is bad or doesn't work for large projects. How one chooses to architect parts of their system or there if there are preexisting conditions affects the effectiveness of other parts.

I don't think it works that way; let hibernate generate the SQL, but you can review it and modify it as you desire. Nobody should rely on tools to manage anything. They facilitate..

Which is a feature as mentioned here in hibernate is not particularly useful from my own experience. A more useful tool that hibernate can provide is something that can generate domain objects and xml mapping file after introspecting the database.

This is bottom up style Data Layer generation and I have used it in all of my projects. Even if the database is to be created from scratch , I find that its cleaner to spend time doing Data modelling based on ERD principles and then build a data layer based on that.

You are absolutely correct. Application design and database design are two different specialties, related as they may be. Applications should always begin with a solid foundation built on data model that addresses relational storage issues, such as getting data in third normal form.

I would never build an application from the top down such as described in Hibernate's schema export feature. Nothing like this approach could really effectively replace DDL and ERD development in anything but a tiny application.

Visit topmindsystems

You are absolutely correct. Application design and database design are two different specialties, related as they may be. Applications should always begin with a solid foundation built on data model that addresses relational storage issues, such as getting data in third normal form.I would never build an application from the top down such as described in Hibernate's schema export feature. Nothing like this approach could really effectively replace DDL and ERD development in anything but a tiny application.Visit topmindsystems

You all are so 80's. :)

Unfortunately OO doesn't not play well with relational and that is what tools like Hibernate try to address. And "top down" can and does effectively replace data modeling. Sometimes the data model does need to be modified, but that is where mapping comes in. The mapping will reflect your data model and you can generate the ddl based on your data model. Plus any additional thing your OR/M requires.

If you don't do OO development then ignore Hibernate and use iBatis or straight JDBC.

Actually we are all so 90's here (when RDBMS took over)

Seriously, I understand your point here but in anything remotely complex, you cannot get away from describing your system in an ERD. Nothing in OO deals with effective data storage/retrieval. For many reasons I think relational databases will be with us for some time, as will OO languages like Java. The challenge is to integrate both worlds.

Visit topmindsystems

... and you are so infatuated.
May we all bow to your mighty judgement of OO development.
May your sword blest truth shall yield.
May your judgement never brittle and to dire fields you veil.

Come off it really, this my-framework-is-oh-so-pure crap is oh so perennial, we really do need a new scenery where people really comprehend that there's no god in the sky, no right answer, no elysian fields, no hibernate and no One True Editor (except emacs).

... no right answer.

I've said that before.

Oh for the ability to read and perform critical thinking.

Oh for the ability to read and perform critical thinking.

What does that mean ?

Oh for the ability to read and perform critical thinking.

What does that mean ?

Thanks for proving my point. :)

Oh for the ability to read and perform critical thinking.

What does that mean ?

Thanks for proving my point. :)

That is a insult.

A brain-dead insult, lacking any style, wit or proof.

Even more insulting is the fact that it's based on your failure to properly utter a phrase combined with my good will in giving you a chance to make amends and possibly rephrase that offensive shit you wrote, possibly in less offensive manner.

But hey, what can one expect from someone who thinks hibernate is more OO and those who don't agree are so 80's? How condescending. First learn to phrase a sentence and then talk back.

That is a insult. ...

And your comments were not insulting? http://www.theserverside.com/tss?service=direct/0/PostNewsReply/postReply&sp=l31149&sp=F&sp=l153221#152866

Yes. I was insulted by your comments. But I didn't figure I needed to resort to bad language. And my post about reading and thinking skills was more general and not so much as directed at you specifically.

I made a statement and you asked a simple question. If you wanted a retraction, you should have made that clear instead of asking a question that said "I have no idea what you mean".

BTW, you might want to check around the internet and find out what :) means.

And as for

But hey, what can one expect from someone who thinks hibernate is more OO and those who don't agree are so 80's?

Please re-read my statements. As in ...

Unfortunately OO doesn't not play well with relational and that is what tools like Hibernate try to address.

Hibernate itself is not more OO (look at my othe posts). But it allows, out-of-the-box, one to work in more of an OO manner in the business/domain layer of an application.

First learn to phrase a sentence and then talk back.

The same could be said for your initial post. Most of it made little sense. But I figured that it refered to things that I was not familiar with (meaning different upbringings). And is problably part of this reason you didn't get what what I was getting at with my post and me with yours.

So, I am sorry you were insulted. But the fact is - people are not really reading other peoples posts and usually not understanding what was said - even if it was clear. They usually read into them. So please re-read the initial post that you commented on then re-read your post. And see who needs to "Take the beam of their eye" (http://bible.cc/matthew/7-5.htm ).

Sorry Mark, my comments were not meant to be insulting but rather point out that your own were casting a judgement on people who don't share your enthusiasm for hibernate and for pointing out the object-relational mismatch every two minutes. Therefore the initial infatuation accusation was mellowed down with hopefully humorous antique expressions.

If you take this quote:

If you don't do OO development then ignore Hibernate and use iBatis or straight JDBC.

you'll see that it has the form A -> B, with:
* A = "do not do OO development"
* B = C & D
* C = "ignore hibernate"
* D = "use ibatis/jdbc"
We all remember our little logic principles, don't we, therefore !B -> !A that is to say:

if not(ignore hibernate & use ibatis/jdbc) then not(do not do OO development)
which further reads as
if not ignore hibernate OR not use ibatis/jdbc then do do OO development
or the English version:
if you don't ignore hibernate, or you don't use ibatis and jdbc, then you're doing OO development.

I'm sure that in spite our different upbringing you will agree that that's a terribly wrong thing to say, and partially one of the reasons I go so terribly aggravated over your initial post.

Your last comment goes:

Hibernate itself [...] allows, out-of-the-box, one to work in more of an OO manner in the business/domain layer of an application.

This again is terribly thin. If you're using Hibernate and your code feels proper, then more power to you. I happen to think that the magick inside hibernate is evil and I much prefer to have as much control over what goes on behind the pretty objects as possible; I know iBATIS gives me that and I think Hibernate does so to a lesser extent, due to the aforementioned magick.

I do not expect any of this to change your mind, but maybe refrain from displaying that slightly arrogant, holier-than-thou/i'm-so-hip-and-much-more-oo-than-you attitude that beckons from your posts.

I cast no judgement (initially) on people, but rather on development technique and technology. It really wasn't even a judgement, but a statement. You can agree or disagree.

Again, you are reading into my sentence. And twisting the obvious meaning. I have clarified multiple times what I meant (even though it was clear).

Grammar is not a mathmatical equation. I got A+s in grammar. You break apart sentences by diagraming them. My statement only says don't use Hibernate for non-OO dev. You assumed the opposite was infered. It wasn't you can do OO dev with iBatis and straight JDBC. It is my experience/belief/position that will have more work and a tougher go of it.

I do not expect any of this to change your mind, but maybe refrain from displaying that slightly arrogant, holier-than-thou/i'm-so-hip-and-much-more-oo-than-you attitude that beckons from your posts.

Not sure why you feel my statements reflect this attitude and decided to attack me, when there are much more definitive statements that have much more holier than thou attitude in this thread.

such as...

I would never let a tool such as hibernate manage my database. It may work on small simple projects, but none thae I have seen.

and

I would never build an application from the top down such as described in Hibernate's schema export feature. Nothing like this approach could really effectively replace DDL and ERD development in anything but a tiny application.

and ... etc.


I can see myself using iBatis on some projects and I can understand why you would use it and never use Hibernate. Oddly you say my statements are arogant and yet so are yours . (ie - You can do a better job then an SQL generation tool )

Nuff said. My apologies to the others on this thread for defending myself.

Right, so that wasn't a judgement, but a pun, let's leave it at that.

As for the grammar thing, when you make an assertion, it has a logical value, and logic says that A->B is equivalent with !B->!A. It is the same thing, however you put it, there is no two ways about it. Let's leave it at that again, and say you should have better phrased that.

If you say you can understand why I'd use iBATIS instead of Hibernate, how does that make me arrogant ? Yes, I can make better use of SQL than most SQL generation tools.
I'm a DBA and a programmer, not the only one I hope, and I also am quite good at both. In the process of becoming a DBA I've worked with loads of ERD/DDL modelling/generation tools, from mylittleframeworkatsourceforge to powerbuilder and erwin. And yes, some of these are real baddies they do a very good job.

I'm a DBA and a programmer

Me too. I don't do backups, etc though. I don't care to be a fulltime DBA. Not my cup-of-tea. I've seldom needed a fulltime DBA. Usually any problem was solved by bringing in a consultant for a day or too. I can only think of one instance. Maybe I have been lucky.

Mark,

Are you saying that if you use Hibreante or O/R your project is more OO?

Creating an Object helps in OO?

Or that if you use E/R, or JDBC or SQL Maps your project is less OO?

Or the things we learned long time ago are less important than what we learned lately? Like Information Theory is from the '40s. Or concordances (of text indexes) is BC. Or SQL tuning from.... 70's I guess.

If so, I propose that you may not know corectly what OO is, what the use of it is, how to use it or what the benefit is.

I'll tell you the sandard way of teachin OO, if you'd like to know (Since I am a certified OO instructor by 2 diferent vendors). It has nothing to do w/ any of above.
"Each generation of langages 1gl, 2gl, 3gl.... we got more producivity via reuse.
Java and OO langages are OO capable. Once can use OO capable langage in a disoriented way, there are no complier flags to tell you. But if you want to improve your producivity via re-use, you can leverage OO capbilibites of a langage. That is the next generation, how we use it.
So if can make a base DAO and extend it.... that may reduce the amount of code I write for each additional custom DAO.
That's all it is. No magic.
It takes practice to think in OO to find re-use. It has been said that a lot of C++ developers use it like it's C.
For example they might do functional decomposition and say this is apples and oranges. In OO you look for how similar apples and orages are and re-use that part. "
Hopefully that helps you be more productive.

Some may also disccount SQL on the basis: "Everything I don't know about, must not be important".
We'll ... if you design large or complex systems, SQL is important and so is E/R and normalization.
One advantage of LAMP is that they do not skip the SQL stage.
If anyone has amibtions to have sucess on larger or complex projects, they will have to master SQL.

Someplace, some marketing said that if you know Java, you don't have to learn SQL. That is for managers and newbiews.

hth,

.V

If you don't do OO development then ignore Hibernate and use iBatis or straight JDBC.

That means that your project is NOT more OO when you use hibernate. Hibernate can help you when you have a domain model and you still have to learn SQL (you can read this also in the hibernate manual).

Reto

If you don't do OO development then ignore Hibernate and use iBatis or straight JDBC.

That means that your project is NOT more OO when you use hibernate. Hibernate can help you when you have a domain model and you still have to learn SQL (you can read this also in the hibernate manual). Reto

There are many ways to use hibernate, but I faund it usefull for conceptual to phisical model mapping. Hibernate supports all ER concepts and it lets to use conceptual model in application (transforma this model at runtime). It is possible to think about it as Object to Table mapping if it sounds better, but it is the same thing. I think the best way to learn Hibernate is to learn ER modeling first, you will see how OO data modeling conceptas and O/R mapping are old, Stone Era :)
http://www2.bus.orst.edu/faculty/brownc/lectures/db_tutor/index.htm

If you don't do OO development then ignore Hibernate and use iBatis or straight JDBC.

That means that your project is NOT more OO when you use hibernate. Hibernate can help you when you have a domain model and you still have to learn SQL (you can read this also in the hibernate manual). Reto

Notice I didn't say SQL? I can do SQL with HIbernate. But then some of the benefit is lost. But even if I don't use any SQL it is still important.

And I didn't say the project was more OO if you used Hibernate.

Mark,Are you saying that if you use Hibreante or O/R your project is more OO?

No.

Creating an Object helps in OO?Or that if you use E/R, or JDBC or SQL Maps your project is less OO?

No. It just fits better with what one is trying to accomplish.

If so, I propose that you may not know corectly what OO is, what the use of it is, how to use it or what the benefit is.I'll tell you the sandard way of teachin OO, if you'd like to know (Since I am a certified OO instructor by 2 diferent vendors).

Please re-read what I wrote.

 It has nothing to do w/ any of above."Each generation of langages 1gl, 2gl, 3gl.... we got more producivity via reuse. Java and OO langages are OO capable. Once can use OO capable langage in a disoriented way, there are no complier flags to tell you. But if you want to improve your producivity via re-use, you can leverage OO capbilibites of a langage. That is the next generation, how we use it.So if can make a base DAO and extend it.... that may reduce the amount of code I write for each additional custom DAO.That's all it is. No magic.It takes practice to think in OO to find re-use. It has been said that a lot of C++ developers use it like it's C. For example they might do functional decomposition and say this is apples and oranges. In OO you look for how similar apples and orages are and re-use that part. "Hopefully that helps you be more productive.Some may also disccount SQL on the basis: "Everything I don't know about, must not be important".We'll ... if you design large or complex systems, SQL is important and so is E/R and normalization. One advantage of LAMP is that they do not skip the SQL stage. If anyone has amibtions to have sucess on larger or complex projects, they will have to master SQL.Someplace, some marketing said that if you know Java, you don't have to learn SQL. That is for managers and newbiews.hth,.V

Hmmm. Is this how you teach? Hmmmm.

Yeah, I agree that if you a have a RDMBS backing the objects, you need to know SQL. Never said differently.

You all are so 80's. :)Unfortunately OO doesn't not play well with relational and that is what tools like Hibernate try to address. And "top down" can and does effectively replace data modeling. Sometimes the data model does need to be modified, but that is where mapping comes in.

Funny to hear that. In eighties we were doing schema update for our apps. Granted, these were not SQL applications, they were dBase-grown PC programs, which evolved into fully compiled Clipper code, running on Novell file servers with indexing NLMs. These were department-scale applications, calculating salary for about 12000 people, supporting HR, projects finanicing etc. Worked with simple DBF files. We did change the schema on the fly, and we also used codeblocks a lot. Codeblocks were the best feature Clipper had, one just had to write an expression, stuff it into a string (or into a database field), and then call eval(). Great stuff.

Anyway, it is the argument of chicken and the egg again. If the database is used by one application only, then schema update may seem as a way to go, but if it is shared (and in enterprise applications,especially in legacy ones it is usually shared) then you cannot do that.

Anyway, the support of an application with frequently updated database is a nightmare. Backup becomes meaningless, because is not possible to restore old data into a new scheme correctly. App versions are hard to support because all they work with different data schema. Data constrains are hard to set on the database level because of its fluid structure. Been there, done that. Thanks, but no.

A more useful tool that hibernate can provide is something that can generate domain objects and xml mapping file after introspecting the database.

Check out Middlegen: http://boss.bekk.no/boss/middlegen/ and http://www.hibernate.org/98.html

And a pretty good tutorial on generating Hibernate from an existing database: http://www.warfrog.com/hibernatetutorial/

Cheers,
Frank

http://java-book-reviews.blogspot.com/2005/01/review-hibernate.html

.V

Didn't get that book cause I didn't see if first. I would like to check it out.

Plus one would think getting things from the horse's mouth would be best.

As for Tom's opinion about O/R Mapping - that is his opinion.
He seems to be overly concerned about performance.

BTW, try this link.
http://dictionary.reference.com/search?q=monolithical

Having been a DBA for over 8 years, and a Java/J2EE Architectect for 4, I can relate story after story of why letting a tool generate your schema in production is generally asking for trouble.

1) For anything other than a small database, the way most tools do the modifications are sub-optimal. Lots of ERD tools try to do this, and instead of taking advantage of the platform's strengths, they do the simple thing, which is usually the worst. For example, when adding a new column to a table, they copy the table and then create the new one, and then copy all of the data from the old table. Great, until you run out of disk space, which the tool didn't check. Or worse, they do it all in a single transaction!

2) Allowing an application to have rights in the database to modify tables is asking for your data to be deleted at 3am. No app is fool proof, and so the app should have the minimum set of rights necessary to get the job done. Especially web apps facing the public internet.

3) Other than a small, internal app, taking the system offline so that the database can be updated will not work. How will the other 4 instances of the application, or worse, the 5 other applications that use the database all know that the new schema has been deployed?

4) Not everything in the db is in the DDL. There are lots of tuning parameters, replication configurations, and other aspects of running a database other than just the schema. The power of Hibernate to hide the SQL (if you want) from the developer also means that they may not be aware of all of what is entailed in managing a database. Just like the DBA shouldn't be expected to understand the details of your super-fast business algorithm, the developer shouldn't assume they know all there is about the database. Unfortunately, too many developers do.

Now, having tools like the author describes are helpful to the developer/deployer/dba. Being able to generate the schema from the data model, and even generate the SQL to do the updates are great. And for a developer trying to figure out how to best model their system, or work with their dba to get the data model and the relational model to a point where they are happy, these all help. Like any other tool, the power to help is the power to hurt.

All bottom up approach and other ER crap is not tolerated by industry at all.
ER is completely replaced by UML Diagrams ,there are number of book that in their newer versions have already replace this ugly diagram eg.
http://www.aw-bc.com/catalog/academic/product/0,1144,0321294017-FEA,00.html

For the bottom up approach:
-How you gana produce your domain models and classes in OO out of a Relational foundation?
-How you gana design the UI where and present your "information"?

Down there in DB we have data, it has to processed to Information in order to be meaningful.

Having been a DBA for over 8 years, and a Java/J2EE Architectect for 4, Allowing an application to have rights in the database to modify tables is asking for your data to be deleted at 3am. No app is fool proof, and so the app should have the minimum set of rights necessary to get the job done.

If the Application is not allowed to modify the data in the DB ,then who and which tool is allowed to do that ??? DBA?
DB is the Data "base" of the application

All these contradictions steams form DBAs and other Relational folks who feel unsecured and invaded by tools that allow developers to make them TRANSPARENT

Peace

are you sure!!!
As Compiere creator Jorge Janke said it: this JDO, Hibernate, etc., is good for those who never understood the relational model.

Have you any experience building large scale (I mean thousands of entities) data models with OOP techniques: I doubt. Then please instead of bashing something that you did not really understand and use , try to learn it!!!


You can use ORM techniques in web applications with data models of moderate sizes(tens of entities): I did it.
But what about creating an ERP application:
-large data models
-complex inter-entity relationships
-need for optimized queries
-very detailed security: entity-level read,write,update permissions
-...

are you sure!!!As Compiere creator Jorge Janke said it: this JDO, Hibernate, etc., is good for those who never understood the relational model.

I don’t care if that dude says Relational is dope, or the other guru says it rocks
As every one knows this model isn't silver bullet. That's why the industry has come up with new data models such as OO and XML, to satisfy different requirements and data type.
Even designer of SQL Don Chamberlin knows that relational is not perfect ,and designed XQuery to support XML model.

Have you any experience building large scale (I mean thousands of entities) data models with OOP techniques: I doubt. Then please instead of bashing something that you did not really understand and use , try to learn it!!!

Learn What ?Realational model?Are you kiddin? Already got it under the belt, even my grandpa knows Relational model.
The one who mast study ,read and research is you and your Relational comrades, who just cant think out side the box (TABLE),and deny and bash any new technology that might compromise your out dated knowledge.
Keywords like complex, thousands of entities, learn it! are used by people who try to fuzz up the discussion and hide their incompetence.

perhaps you have something to learn from your grandmom.
Look, it is unfortunate for me to be in a position to defend relational model against object model but the truth is that a strong relational model is the most important difference between successfull and failed enterprise projects: The best proof is demise of EJB. The designers of EJB had the same mindset as you. They thought that they could "ignore" database since it is "just a datastore". The result is evident.

I suggest you read Rod Johnson's J2ee design book.

the truth is that a strong relational model is the most important difference between successfull and failed enterprise projects: The best proof is demise of EJB. The designers of EJB had the same mindset as you. They thought that they could "ignore" database since it is "just a datastore". The result is evident.I suggest you read Rod Johnson's J2ee design book.

+1.

This is why EJB 3 and EjB 4 will fail at enterprise projects. O/R works on simple small scale, that's all.
Another proof is that once O/R person learn E/R SQL based mapping... they convert. Look at iBatis. A lot of people there tried O/R.
I tried O/R (via EJB) in proudction.
All I am saying... be open minded to learn something and not have just one tool in your hand.

hth,


.V

This is why EJB 3 and EjB 4 will fail at enterprise projects.

If it looks/works anything like current day EJB.

 O/R works on simple small scale, that's all.

(BTW, It is O/R Mapping). It does work and scale. EJB != ORM.

Another proof is that once O/R person learn E/R SQL based mapping... they convert. Look at iBatis. A lot of people there tried O/R.

I never want to go back to handling the SQL all by my self and definitely not having to handle the mis-mismatch between OO and Relational.

I tried O/R (via EJB) in proudction.

So you've not tried OO/R mapping? :)
I understand your point with mapping EJBs to a relational model (and then trying to do OOP in the rest of the application).

You sound pretty closed minded to Hibernate and other more modern O/R Mapping tools.

All I am saying... be open minded to learn something and not have just one tool in your hand.

Oh. How odd.

You mean open minded like this?

No tool/api/framework is perfect. It takes someone with ability to determine when and where to use what and how.

Just because a tool doesn't work the way you like to work doesn't mean it is bad or doesn't work for large projects. How one chooses to architect parts of their system or there if there are preexisting conditions affects the effectiveness of other parts.

Mark,

Check these threads, if you want to try to absorb:

http://sourceforge.net/forum/message.php?msg_id=2628174
http://sourceforge.net/forum/message.php?msg_id=2695900
http://sourceforge.net/forum/message.php?msg_id=2291789

I am sure that if you tried this:
http://www.ibatis.com/common/example.html
you would see why it matches better. But you don't have to, in Java, one can make good or bad choices, it's up to you, depending on scale of projects you work on.

hth,
.V

They pretty much said what I said.

From the last link:

Those with a procedural background tend to align better with iBatis and pride themselves in optimizing query statements and caching. Their applications tend to be very procedural and assume that clock cycles are expensive.My opinion is that their applications are somewhat less flexibile because many SQL statements change when the database structure changes.

And

Those that started with an object oriented background work better with Hibernate.

Maybe in some special cases, people with less experience have a better point than people w/ more experience. I hope that in this case a few years from now, as one gain more experience, one do not start loosing credibility. Like C# is newer.

Again about O/R makes your code more OO. Like water over the stone, I give up. But I did register that O/R people think that it makes their code more OO.
Maybe their entire career they never run into a larger or more complex project.

.V

Maybe in some special cases, people with less experience have a better point than people w/ more experience.

True. But that is not the case here.

 I hope that in this case a few years from now, as one gain more experience, one do not start loosing credibility. Like C# is newer.

????
The quotes were from the link you provided. So now are those links bad?

Again about O/R makes your code more OO.

Again - Nothing. But those frameworks who handle more of the O/R relationship are a better fit. BTW, iBatis is a O/R mapping tool.

Like water over the stone, I give up.

I'm sorry you don't understand. It is all there in print.

But I did register that O/R people think that it makes their code more OO.

Not sure where you are getting that from. Get the Hibernate in Action book.

Maybe their entire career they never run into a larger or more complex project..V

Have you used something like Hibernate on a large or complex project? Not EJBs.

I never want to go back to handling the SQL all by my self and definitely not having to handle the mis-mismatch between OO and Relational.

"impedence mis-mismatch" is myth, authors use it to sell object databases. Any good O/R tool like Hibernate just transforms ER modeling concepts to implementation. Direct trasformation exist from conceptual ER model to implementation model and transformation rules are well known (hibernate uses the same rules if yo do not pullute model yourself), both ER models work very good with OOP. Sometimes it makes more sence to implement this transformation at development time for performance reasons.
Tools like iBatis or direct JDBC calls can help in this case. It is not easy, but there is nothing wrong to optimize application (it is not easy to learn O/R tools too).

"impedence mis-mismatch" is myth, authors use it to sell object databases. Any good O/R tool like Hibernate just transforms ER modeling concepts to implementation.

Maybe they do/did use impedence mis-match to sell their product. But it doesn't lessen the reality of it.

I suggest you read pages 7 to 16 of Hibernate in Action.

I suggest you read pages 7 to 16 of Hibernate in Action.

I have read it, it is a good book, but I like to find more information than opinion in books.

I suggest you read pages 7 to 16 of Hibernate in Action.

I have read it, it is a good book, but I like to find more information than opinion in books.

Guess we will have to agree to disagree. I've seen the mismatch long before Hibernate and Java. Even with VB.

Of course, if there is no mismatch then there should be no problem using O/R Mapping tools in large and/or complex applications. :)

Of course, if there is no mismatch then there should be no problem using O/R Mapping tools in large and/or complex applications. :)

Yes, there is no problem to use O/R Mapping and web application is a good candidate (The same is about iBatis or EJB). Results more depend on developer than on framework anyway.
BTW
If you can map two models then they match. It is trivial, is not it ?

Schema Export is useful for acceptance testing where you can simply drop and create a database (using XDoclet generated HBM files and the schema export Ant task), populate it with the sample data, then run your acceptance tests.

The 'schema update' task doesn't work so well with legacy databases. You need to use another tool (and a dba) to work out what the upgrade scripts should do. Its a lot more complicated.

Kim Pepper

Just a quick question, does the hibernate schema generator tools supports the creation of indexes and referential constraints?

Just a quick question, does the hibernate schema generator tools supports the creation of indexes and referential constraints?

Sure. It generates primary and foreign key constraints for all the tables that are mapped against objects.

While hibernate-driven schema management absolutely rocks, I failed to find a proper solution to get Hibernate generate type=InnoDB mappings for MySQL (skip the flame, client's choice :-).

I've read the FAQ on hibernate.org, but I'm doing schema extraction from my own java class (a test case actually), and I couldn't find any other appropriate solution beside getting the drop/create scripts in String[] and sed manually all create tables to be 'create table .. type=InnoDB'-s.

Anyone got a nicer solution for the problem?

Kristof,
In the my.cnf, you can set mysql to use InnoDB as default. You have to add an entry that says default-table-type=INNODB
(or it might be storage_engine=INNODB)

Thanks Dan,

I had done right that on my local machine, the problem uprised next when most of my tests failed on the cruisecontrol box :). I would have favoured a global setting there too (really, what's the point in a DB w/o transaction support :), but the admins of the box preferred a local solution..