takisd wrote:
perhaps i should use it purely for object mapping (???) and rely on my existing jdbc calls for the 'funnies'.
that is it. Think a bit logically here: you have a database, which is flat (3D space - field, record and relation). You as a developer want soemthing more manageable (not neccesarily less complex) objects (this is about 5D space - you add inheritance and polymorphism and a whole buch of other stuff, so it might be even more than 5D). Hibernate will help translate between the two, but it all costs something; no surprise here.
Now some operations are meant to be in 3D space, while others for the sake of manageability and ease of use/reuse, and ease of expansion better be in 5D. So it is up to you what you want to leave in 5D and what you want in 5D. Hibernate is just a link. Remeber back in the days you studied linear algebra, guess what, you thought you were studying the shit you will never need :-). Well it comes back to haunt you here! If you rember how clamsy that equation for a plane was in 3D spaces, and how nice and simple and yet mysterious it was in N-Space, he he the same is true here.
Your confusion is very much familiar to me; I have a lot of arguments with my boss, who refuses to get off the stored procedures. He motivates it with, well they can do everything. This statement is of course true, until we need to move from database A to database B (well that is a business decision, not a technical one) and all of his 1000 procedures that were developed in the course of 4-5 years are invalid overnight. While majority of theese procedures do not do more than a simple select, there are maybe a handfull that do usefull stuff that I would never even think of getting rid of; Like procedures that need to lock 50,000 records do calculation and do addition of a new record or deletion of old one, based on the result of the calculation. If I start mapping those 50K recs into 4D space ... well that will just be stupid. So use your own judgement and try to understand the use of ORM in general, what it bring to your plate and waht it takes away from it. Once you do the rest is easy, just use the strong features of both worlds to your own advantage and your programs will be as agile as they can possibly be :-) while satisfying your business requirements.
HTH,
Alex