Talking about Hibernate can get me onto rants in a way that competes
with Word ;-)
But seriously: your assumption is that
(a) abstraction is good per se; and
(b) the model Hibernate abstracts into is a good one.
Regarding (a) I say that pretty much every time I have seen work done
using Hibernate, I have seen discussions about:
(1) what the object model should look like;
(2) what the relational model should look like; and
(3) how to map the two together.
So instead of talking about one model, you suddenly have to design and
map two. I don't see how that helps. Hibernate as an abstraction leaks
like a bucket after being under 5 minutes of machine gun fire.
Regarding (b): it is currently still favorable to consider OO the best
way to do things. Having done about 15 years of it I am not convinced of
that at all. In fact: I nowadays believe much more in relational algebra
than OO as a modeling tool. Putting things like a matrix-vector product
on either matrix or vector just doesn't make sense to me, neither does
putting intersection on a shape object. These are objects that have
intrinsic features, but those methods are not intrinsic but part of a
larger system a mathematician would call algebra.
The system I would like to see is something that gives you the true
power of relational algebra integrated into a modern programming
environment. SQL is significantly different from relational algebra and
many RDBMS don't support structured column types (or objects). Hibernate
takes the SQL view and moves it even further away from relational
algebra. That is not an improvement from my perspective.
To get out of the abstract and into an example, here some spatially
enabled SQL code (untested, but should work plus/minus some typos I
probably will put in):
SELECT field1, field2, field3, ST_Union(the_geom) FROM someTable
GROUP BY field1, field2, field3;
This gives you all the shapes for which fields 1-3 are the same
(assuming the_geom is a geometry field on the original table). I can do
this using Hibernate (there are spatial extensions at least for
PostGIS), but trust me: that's no fun. It involves quite a bit of
looping and logic, and will be inefficient. I could possibly use
JPQL/HQL, but that would look more or less like the query above.
The point I am trying to make is that there is a whole class of problems
for which relational algebra (or even SQL's tuple calculus) are a much
better solution. By forcing the solution domain to be OO you don't
really help that much. Of course it makes for an easier start for the
non-SQL-savvy developer, but using a saying I learned on this list:
"it's like pissing your pants: nice and warm at first, but not really a
good idea".
I guess a lot of my cynicysm comes from people giving up on relational
databases due to the way they are implemented. People took shortcuts in
the 70s (nulls come to mind), in the 90s everyone decided the database
has to be a commodity while at the same time the vendors did everything
to avoid exactly that. The result is that RDBMS can be a pain, but that
is no justification to claim relational algebra as a failure. I somehow
hope the revival of the functional paradigm will move things back a bit.
Just my 2c.
Peter
On 14/07/10 13:06, jitesh dundas wrote:
> Well,there are issues over every software,don't you think? There is a
> need for certain aspects ,especially in configuration set-up, in
> hibernate.
>
> Still, this is 1 step forward towards abstraction of coding , a layer
> higher than the existing one.
>
> In any case, coding efforts are going in the right
> direction...Hibernate too, is one of those, but it does need some
> fixes...
>
> Thanks for the update .
>
> Regards,
> jd
>
> On 7/14/10, Peter Becker <peter.becker...@gmail.com> wrote:
>> On 13/07/10 22:41, jitesh dundas wrote:
>>> Have you heard of Hibernate/Spring for hiding DB related issues..
>> It hides them so well that it usually takes at least 10 times longer to
>> fix them. It does so by layering a coat of its own issues over the DB.
>>
>> Peter (who tends to get cynical when hearing "Hibernate" or
"Spring").
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "The Java Posse" group.
>> To post to this group, send email to javapo...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> javaposse+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
