This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

wondered why this dangerous option is available is has a high risk to kill the db

regards

It is convinient (or at least may be convinient) during development, BTW, the whole HibernateTools package is development, not production oriented. Any decent database (I mean DB size) needs a lot of manual schema tuning to optimize performance which is DB-specific and can not be done with this tool.

There is another reason (IMHO) the whole phylosophy of Hibernate is to provide a user with any and all imaginable options and allow him to select what suits him more. The whole book that I have mentioned is ovecrowded with statements like "Hibernate supports option XXX, but we do not reccomend to use it".

It is convinient (or at least may be convinient) during development, BTW, the whole HibernateTools package is development, not production oriented.

sad to read that

The whole book that I have mentioned is ovecrowded with statements like "Hibernate supports option XXX, but we do not reccomend to use it".

really wondered

well, i have this situation,
my system are in a 95% to finish and my boss want all the system working,
i told him about that if he want a new requeriments maybe can happens one of the 3 options already written

Code:

1:what happens if now in my hbm files i create for the old tables more fields?
2: i create new tables
3: for these new tables maybe can now has relations to the old tables

so now friend,
you told me that hibernate cant does this job,
what reasonable options i have for this situation?

regards and thanks in advanced

Comment

Write the new/update old files, generate scripts to update database schema with hbm2ddl.update by redirecting output to the file (it is described in the Hibernate reference, 20.1.5, 20.1.6), test them throughfully and only then apply to the production DB. Just few more step involved.

BTW, I myself do not use automatic generation tools and always write DB scripts manually, but I do not use Hibernate so much anyway.

well, i have this situation,
my system are in a 95% to finish and my boss want all the system working,
i told him about that if he want a new requeriments maybe can happens one of the 3 options already written

Code:

1:what happens if now in my hbm files i create for the old tables more fields?
2: i create new tables
3: for these new tables maybe can now has relations to the old tables

so now friend,
you told me that hibernate cant does this job,
what reasonable options i have for this situation?

thats the problem the boss want the system to enter to production in a 95% and i am afraid to listen, "i want this....." and change the db schema

Write the new/update old files, generate scripts to update database schema with hbm2ddl.update by redirecting output to the file (it is described in the Hibernate reference, 20.1.5, 20.1.6), test them throughfully and only then apply to the production DB. Just few more step involved.

i will read carefully that, coz i dont how do that ,thanks for the tip

BTW, I myself do not use automatic generation tools and always write DB scripts manually,

so you dont use your hbm mapping files to create the tables?

wooh, how you manage at least 50 tables with 20 fields ? manually?

regards and thanks for your time

Comment

There are DB designer tools that like ErWin or PowerDesigner that can (and should) be used to design db schemas. Anything else will, on any project of a decent size, sooner or later, end up as another IT disaster.

Comment

thats the problem the boss want the system to enter to production in a 95% and i am afraid to listen, "i want this....." and change the db schema

i will read carefully that, coz i dont how do that ,thanks for the tip

so you dont use your hbm mapping files to create the tables?

wooh, how you manage at least 50 tables with 20 fields ? manually?

regards and thanks for your time

Never was in position to do it - never have used Hibernate for such kind of applications. The biggest application that I have done with Hibernate had about 10 tables (w/o Hibernate - about 300 tables ).

First of all, I woul rather start from DB tables, then Java objects and only then - mappings. But in any case I would use a tool only for initial generation and not for the evolution (except validation mode of hbm2ddl).

Do not forget that data in DB have tendencies to outlive any given application (if not technology) and to be shared with many ones (even if it was not initially supposed). So DB data structures is of utmost importancy.

Regards,
Oleksandr

Comment

There are DB designer tools that like ErWin or PowerDesigner that can (and should) be used to design db schemas. Anything else will, on any project of a decent size, sooner or later, end up as another IT disaster.

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

The biggest application that I have done with Hibernate had about 10 tables (w/o Hibernate - about 300 tables ).

pretty number

First of all, I woul rather start from DB tables, then Java objects and only then - mappings.

right order, same approach i do

Do not forget that data in DB have tendencies to outlive any given application (if not technology) and to be shared with many ones (even if it was not initially supposed). So DB data structures is of utmost importancy.

thats right, the baseline of the rest of the layers

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

lower programming is powerful always, Erwin for few tables is nice, but for a lot
is a wonderful hell

regards

Comment

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

For you perhaps, but you are not writing the application and documentation for yourself.

You should have many diagrams, showing different facets of the schema. One diagram representing all the tables of a non-trivial system is as usefull as reading a telephone book from cover to cover.