Let's say I have a persistent object called Article (table is called 'article') and it has a list of persistent ArticlePages (where the table is called 'article_page').
I'm having a problem that Hibernate fails to insert new rows into article_page because it doesn't include the article_id in the article table (and yes, the Article object has been saved and commited by the session and *it is* in the database. Thus, it's definately a problem with the sql statement generation.
The exception I actually get is that the statement can't execute because it fails a referential integirty constraint (pretty obvious from my description of the problem above).
Now, it doesn't have anything to do my with db server (mysql in this case) since this is a pretty easy thing to do really. I've tried all the examples and every form of lists (bags, sets, maps, etc.) and I get the same error for all of them. Thus, I really think it's a bad build of the software recently, but they haven't fixed it.
Thus, should I just drop hibernate and roll up my own thin-wrapper and support framework around jdbc (no automated mapping)? I could probably roll out that framework in a day or two, so that's not too bad. I don't want to make a full-blown mapping solution, but I could do that in 2 weeks probably if I find the time.
I'm just disappionted that Hibernate works for everything else, so I really got my hopes up that it was a perfect solution. However, besides this there are a bunch of other problems with it that I found out while playing with it
- the exception that says "no persister class for this entity" says nothing to the developer. What it should have said was that you didn't store the mappings into the Hibernate session (or was it session factory?) object.
- The overlap of properties and xml configuration files. This is pretty crap since it leads to a lot of problems. the mappings field also doesn't matter in practice, leading to the problem described above.
- it throws too many checked exceptions and required me to create a few framework classes to simplify the code. This was an obvious failing in JDBC and they mirrored it perfectly.
- The saveOrUpdate() method is pretty unstable, even if configured for it. I had some problems with it that I just made my own that always worked.
Don't get me wrong.. Hibernate had a lot of promise and I resolved the points noted above, but this list/bag/set/map problem is really annoying me and after trying lots of stuff in my code and my xml mapping file, I have to conclude it has to be something wrong with the framework itself. Thanks for the suggestions in advance.
Regarding you original problem...perhaps if you posted your code the problem would be easier to diagnose. I'm currently using Hibernate in production and have not experienced this problem. Also, what version of Hibernate are you using? What environment?
Also, you probably get better help on the Hibernate forum:
What's the relationship between Hibernate and other persistence technologies like EJB, JDO, Toplink etc?
Hibernate is most similar to TopLink as they are both O/R mapping tools. However, Hiberante is open source and TopLink is commercial.
Would you be tied to Hibernate or does the paradigm support somw kind of DAO to insulate changes between Hibernate and CMP for example?
You can insulate you application's dependency with your design. Let say you are using the Value Object pattern with you entity beans (your EJB's accept/return coarse-grained POJOs). If you you are using CMP, your architecture may look like this:
Session Facade -> CMP Entity Bean -> Database
You can easily replace this with:
Session Facade -> BMP Entity Bean -> Hibernate -> Database
or better yet:
Session Facade -> BMP Entity Bean -> DAO Interface -> Hibernate -> Database
By using the final design, you can have you Entity Bean expose the available persistant methods to the rest of your application, but behind the scenes you can have either a CMP bean, or a BMP that talks to an abstract DAO layer. This layer can be implemented with JDO, an O/R framework (e.g. Hibernate) or straight JDBC.
What do you think about using
Session Bean >> DAO Interface >> Hibernate >> DB
BMP would make things more complex for simple application.