Hibernate version:3.1.2

hi all, even though i've been using hibernate for sometime, i never tried on the performance ,stability and mainly scalability issues of hibernate .

Can anyone explain about the feasibiliy of using hibernate on a highly database centric mission critical application which may involve a thousand tables ? And what if the data that is handled is highly sensitive and need concurrent access? A possible example , say an application on financial domain like electronic fund transfer, core banking systems ..etc or an
ERP system ...

please give me suggestions from your experiences ..

Thousand tables will cause slow startup time because Hibernate needs to parse and enhance bytecode for thousands of classes. Other than that H does not do any magic and its performance is OK but of course depends heavily on the way the mapping files are written.
I would expect that for database with such a big schema and presumably great deal of data in it I would expect a need for DB specific or case specific optimization where you might need to resort to straight SQL. Which Hibernate supports but you may find better support for heavy SQL use in frameworks like iBatis.
The question of concurrency is important one, but Hibernate does not do any magic here: it does what you would most likely to do anyway. And again for heavy use of DB specific features you might need to use SQL.

"..may find better support for heavy SQL use in frameworks like iBatis"

could you please elaborate that in details ? (what do we not support besides of in/out for stored procedures)

Please see this thread where you have asked the same question and I have answered it:

http://forum.hibernate.org/viewtopic.ph ... ght=ibatis

I would add that H does not maps result set to an arbitrary classes by properties and requires a constructor that would take all the arguments, very inconvenient for more than 4 arguments...

ah yes, that old thread but alot has changed since then...i would like a fresh update ;)

Well, than I did not notice that any of my bullets were addressed.
Links please?

a. for scalars it requires declaring them;

no true anymore. we auto detect it now.

b. does not support conditional queries ie. Depending on condition there might be different ORDER by or WHERE clauses used;

Same answer as last time + one could create this as an "addon"
(last time answer: true, might be usefull - also in context of HQL queries; but very few actually asked for it and it complexify the cachability of the query.)

c. does not map to Map by default;

when i get my hands free I want to add this support to 3.2 - but patches very welcome ;)

d. does not support reusing of named mappings (column to class-property maps )

not true anymore as said in the thread.

Thanks Max,

Then update documentation please:
http://www.hibernate.org/hib_docs/v3/re ... medqueries


How about my last addition: using setters to populate arbitrary classes (do NOT require constructor) from HQL or SQL result sets?

Anyway I do not think that Hibernate should incorporate all kind features iBatis has exactly because reasons you have hinted: complexities for caching, relationships tracing etc. etc. etc. Hibernate in my opinion is getting more and more bloated with unnecessary features like XML sessions and auto generation of DB schema. Hibernate is loosing targeted approach that caused it to become so successful.

In my opinion there are situations where Hibernate is clear winner and situations where iBatis is more appropriate. That is why I suggest in certain cases to use both.

Just let it be this way, enough is enough, scope creep is very dangerous thing. Bash does not try to include awk and sed but allow using them easily. This principle makes Unix systems shine and it used to serve Hibernate well, because of the targeted approach Hibernate won against JDO and EJB....

OK, enough ranting, I wish you good luck and be stuck to common sense

well we are definitly not adding features we don't find usefull or not needed ;)

Having "property based injection" of beans instead of "constructor based" is something I find usefull and wanted to add for a while.

btw. auto creation of schemas have been in there for ages..e.g. hibernate 0.9 ;)

and I consider it as evil for aeons :)

hehe yes, people think it should not be reviewed by a DBA before used in production; but for ease of use/testing it is Good.

Disagree: it is good for quick and dirty testing but not that good for real thing when all the constraints, triggers and indexes should be in place. I would say that auto generation of DB schema promotes sloppiness, but many people disagree with me :)

yes - quick and dirty testing is what it should be used for.

I would hate if we had to write all the needed DDL for all db's by hand to perform hibernate unit testing.

Too bad, writing SQL manually especially for unit tests would significantly improve their quality.

By the way in my H tests I do create DDL and test data scripts manually and that is not that big of a deal.

thanks for the reply guys . but i didnt really get a conclusion :)