«

On 5/3/2012 2:44 PM, Leif Roar Moldskred wrote:
> Arne Vajhøj<> wrote:
>> On 5/1/2012 11:08 PM, Leif Roar Moldskred wrote:
>> True.
>>
>> But I can not see anything being better than JPA in relation
>> to having a stable API where changes to the ORM does not require
>> changes in the ones own code base.
>
> Possibly, but some other ORMs, like Hibernate, have been about as
> stable as clay.

I have also been burned by a couple of Apache projects.

But while we often complain that the JCP process is too slow and that
they are too conservative, then avoiding too many breaking changes
is one big benefit of what they do.

> [1] The real problem with ORMs here is perhaps not so much that they
> prevent you from getting down to the metal with the database, but that
> you end up with hardly any developers who has the raw database skills
> to do it.
>
> I think one can make an argument that to use an ORM efficently,
> _someone_ on the team needs to have a good grounding in fundamental
> database theory, but new developers don't get that grounding from
> developing with an ORM.

I completely agree.

ORM's is a productivity tool but developer should still
have a good database and SQL understanding.

One thing that makes me dislike an ORM is if it comes
with a foobarQL where you can not get to see the real
SQL send to the database.

Arne

On 12-05-03 02:51 PM, Arne Vajhøj wrote:
> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
>>> On 4/30/2012 5:55 PM, markspace wrote:
>>>> I'm making a small website as a personal project using only the JDBC
>>>> interface. (No ORM, etc.) Well, I did the CRUD for exactly one bean and
>>>> found it pretty tedious going. So I started looking around for
>>>> something
>>>> light-weight to help me out. I found the Apache commons dbutils
>>>> project:
>>>>
>>>> <http://commons.apache.org/dbutils/>
>>>
>>>> And: is there a better, light-weight non-ORM package that you might
>>>> recommend instead? Something a bit more complete.
>>>
>>> What are you actually gaining by not using a full blown ORM
>>> (JPA, traditional Hibernate etc.)?
>>
>> Precisely so that you don't have a full-blown ORM with either a native
>> API or JPA. I'll give you an example: I do integrations with lightweight
>> ESBs [1], and sometimes I might have to write some simple JDBC in
>> components and all I want are some Java Beans to represent the ResultSet
>> rows. Just for packaging. Something like DBUtils could be handy (in fact
>> I'm delighted that markspace reminded me of this handy API). I
>> definitely don't want a full-blown JPA ORM in that environment.
>>
>> Like I said in another post, if you make an argument that a full-blown
>> ORM is always preferable to a lightweight one, that's practically
>> tantamount to saying that it never makes sense to use JDBC either.
>
> If we are talking about "single row centric" then I would go for
> either the heavy ORM to get functionality or plain JDBC to avoid
> dependency (the last argument is more or less a SE only argument).
> I would find it difficult to see a good argument for going with
> the light ORM.
>
> For "multi row centric" then I would go for plain JDBC as
> ORM is not intended for that.

I think I'd analyze it probably the same way. Usually.

However, the situation I am describing here - it's one example, there
are others - is one where I don't want JPA or native ORM units-of-work
or anything barely above raw JDBC. It's simply the case that from time
to time I might want to package a ResultSet row as an object, with zero
special meaning. That's all I'm saying.

It's not like I often have this requirement. 90+ percent of the tiem
it's JPA for me, almost all of the rest is plain JDBC. Using a simple OR
mapper like DBUtils would be very occasional.

>>> I doubt that you will save any code in your app.
>>
>> Likely not. That's not why you'd pick a rudimentary mapper.
>>
>>> I doubt that the less memory usage will be noticeable.
>>
>> Likely not. It's not why I'd make a decision.
>>
>>> It is not really a problem that the full blown ORM is hundreds
>>> of thousands of lines of code, because maintenance is not
>>> your responsibility.
>>
>> It's not, no. But that full-blown ORM with 500,000 lines of code (pretty
>> close to what EclipseLink 2.2 has in its 'org' package [2]) is going to
>> have quite a few more defects than an ORM with 5,000 lines of code
>> (DBUtils has about 8,000 [2]).
>
> That is obvious true, but I don't know if it is relevant.
>
> If we follow the traditional rule of 1 bug per 1000 lines
> of code, then we will see:
>
> 500 KLOC => 500 bugs
> 5 KLOC => 5 bugs
>
> But there are two things to remember:
> 1) The same usage will only use a smaller portion of the large library.
> 2) This is when delivered first time. Bugs get fixed as they get found.
> The more the code is used the faster the bugs get found.
>
> If we compare the 500 KLOC library with the 5 KLOC library then
> doing what the small library can do may only use 25 or 50 KLOC of
> the large library.
>
> If that is the case and the larger library is used so much more than
> the smaller library (and the functionality of the larger library
> that can be done by the smaller library is most likely the
> functionality most used) that there are 5 or 10 times less bugs
> left per size, then there may actually be fewer bugs left.
>
> Is this just number magic? I don't think so!
>
> If you want a stable OS and a stable database would you go for
> an exotic product with a small code base or a well known
> product with a much larger code base?

The LOC count isn't one that I'd use to make the decision, Arne.
Although I'd certainly read the bug database to find out what could hurt.

You mentioned maintenance, not me, and I know from bitter experience
that ORM problems are *my* problems.

But I'll reiterate that if I went with a small, very rudimentary mapper
that it would be special case and a situation where a full-blown ORM
would be massive overkill.

>> No particular aspersions on EclipseLink, but when one of those defects
>> is hurting *your* project, even with access to source it's not
>> straightforward to fix it, and it's not an overnighter to get the EL
>> team to do so either. With as few lines of code are in DBUtils source,
>>
>> *I* can fix it, and readily.
>
> I would not want to fix it. I would want something where you can report
> the bug to someone and let them fix it.

You have no real choice with a large ORM anyway. You report it, and if
you're lucky a few minor versions down the pipe and a few months later
you see a fix.

>>> And some of the capabilities (like caching) could become
>>> very handy in the future.
>>
>> The operative word being "could". Leaving aside the other management
>> capabilities of the persistence context Level 1 cache, like uniqueness
>> of identity within a PC, if you are constructing objects with a simple
>> mapper like DBUtils you *have* a cache. Your objects are in memory;
>> you're not hitting the DB every time you need them.
>
> That is not really level 1 cache.

What do you consider to be a cache? A cache means that you've got your
stuff in a storage area that's faster to access than the original
location. Usually memory. If I get my stuff through JDBC, and access
data afterwards off the ResultSet, that's a cache. If I convert that
ResultSet to a collection of objects, and access data in that collection
afterwards, that's a cache.

Insofar as this level of caching is similar to a persistence context,
which is referred to as Level 1 in JPA, I have no problems thinking of
it as Level 1 equivalent.

>> As for JPA Level 2, well, that's a decision best approached carefully
>> and not made available by default. I surely don't think you need to go
>> with JPA just in case you might need Level 2 cache at some point.
>
> If it was just that: no. But there are other features that also could
> become useful.
>
> Arne

Hopefully you know what you need early on, considering as how you did
good requirements analysis. In which case you're using JPA because you
already know you need it.

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
>>>> On 4/30/2012 5:55 PM, markspace wrote:
>>>>> I'm making a small website as a personal project using only the JDBC
>>>>> interface. (No ORM, etc.) Well, I did the CRUD for exactly one bean and
>>>>> found it pretty tedious going. So I started looking around for
>>>>> something
>>>>> light-weight to help me out. I found the Apache commons dbutils
>>>>> project:
>>>>>
>>>>> <http://commons.apache.org/dbutils/>
>>>>
>>>>> And: is there a better, light-weight non-ORM package that you might
>>>>> recommend instead? Something a bit more complete.
>>>>
>>>> What are you actually gaining by not using a full blown ORM
>>>> (JPA, traditional Hibernate etc.)?
>>>
>>> Precisely so that you don't have a full-blown ORM with either a native
>>> API or JPA. I'll give you an example: I do integrations with lightweight
>>> ESBs [1], and sometimes I might have to write some simple JDBC in
>>> components and all I want are some Java Beans to represent the ResultSet
>>> rows. Just for packaging. Something like DBUtils could be handy (in fact
>>> I'm delighted that markspace reminded me of this handy API). I
>>> definitely don't want a full-blown JPA ORM in that environment.
>>>
>>> Like I said in another post, if you make an argument that a full-blown
>>> ORM is always preferable to a lightweight one, that's practically
>>> tantamount to saying that it never makes sense to use JDBC either.
>>
>> If we are talking about "single row centric" then I would go for
>> either the heavy ORM to get functionality or plain JDBC to avoid
>> dependency (the last argument is more or less a SE only argument).
>> I would find it difficult to see a good argument for going with
>> the light ORM.
>>
>> For "multi row centric" then I would go for plain JDBC as
>> ORM is not intended for that.
>
> I think I'd analyze it probably the same way. Usually.
>
> However, the situation I am describing here - it's one example, there
> are others - is one where I don't want JPA or native ORM units-of-work
> or anything barely above raw JDBC. It's simply the case that from time
> to time I might want to package a ResultSet row as an object, with zero
> special meaning. That's all I'm saying.
>
> It's not like I often have this requirement. 90+ percent of the tiem
> it's JPA for me, almost all of the rest is plain JDBC. Using a simple OR
> mapper like DBUtils would be very occasional.

Hard to argue against anything being a good choice "very occasional".

Occasionally the requirements are slightly different than the usual.

>>>> I doubt that you will save any code in your app.
>>>
>>> Likely not. That's not why you'd pick a rudimentary mapper.
>>>
>>>> I doubt that the less memory usage will be noticeable.
>>>
>>> Likely not. It's not why I'd make a decision.
>>>
>>>> It is not really a problem that the full blown ORM is hundreds
>>>> of thousands of lines of code, because maintenance is not
>>>> your responsibility.
>>>
>>> It's not, no. But that full-blown ORM with 500,000 lines of code (pretty
>>> close to what EclipseLink 2.2 has in its 'org' package [2]) is going to
>>> have quite a few more defects than an ORM with 5,000 lines of code
>>> (DBUtils has about 8,000 [2]).
>>
>> That is obvious true, but I don't know if it is relevant.
>>
>> If we follow the traditional rule of 1 bug per 1000 lines
>> of code, then we will see:
>>
>> 500 KLOC => 500 bugs
>> 5 KLOC => 5 bugs
>>
>> But there are two things to remember:
>> 1) The same usage will only use a smaller portion of the large library.
>> 2) This is when delivered first time. Bugs get fixed as they get found.
>> The more the code is used the faster the bugs get found.
>>
>> If we compare the 500 KLOC library with the 5 KLOC library then
>> doing what the small library can do may only use 25 or 50 KLOC of
>> the large library.
>>
>> If that is the case and the larger library is used so much more than
>> the smaller library (and the functionality of the larger library
>> that can be done by the smaller library is most likely the
>> functionality most used) that there are 5 or 10 times less bugs
>> left per size, then there may actually be fewer bugs left.
>>
>> Is this just number magic? I don't think so!
>>
>> If you want a stable OS and a stable database would you go for
>> an exotic product with a small code base or a well known
>> product with a much larger code base?
>
> The LOC count isn't one that I'd use to make the decision, Arne.
> Although I'd certainly read the bug database to find out what could hurt.
>
> You mentioned maintenance, not me, and I know from bitter experience
> that ORM problems are *my* problems.
>
> But I'll reiterate that if I went with a small, very rudimentary mapper
> that it would be special case and a situation where a full-blown ORM
> would be massive overkill.

Yes.

And I am sure that such cases do exist.

I am just trying to argue that in most cases a big
jar files is not a problem in itself.

>>> No particular aspersions on EclipseLink, but when one of those defects
>>> is hurting *your* project, even with access to source it's not
>>> straightforward to fix it, and it's not an overnighter to get the EL
>>> team to do so either. With as few lines of code are in DBUtils source,
>>>
>>> *I* can fix it, and readily.
>>
>> I would not want to fix it. I would want something where you can report
>> the bug to someone and let them fix it.
>
> You have no real choice with a large ORM anyway. You report it, and if
> you're lucky a few minor versions down the pipe and a few months later
> you see a fix.

This is the industry way.

>>>> And some of the capabilities (like caching) could become
>>>> very handy in the future.
>>>
>>> The operative word being "could". Leaving aside the other management
>>> capabilities of the persistence context Level 1 cache, like uniqueness
>>> of identity within a PC, if you are constructing objects with a simple
>>> mapper like DBUtils you *have* a cache. Your objects are in memory;
>>> you're not hitting the DB every time you need them.
>>
>> That is not really level 1 cache.
>
> What do you consider to be a cache? A cache means that you've got your
> stuff in a storage area that's faster to access than the original
> location. Usually memory. If I get my stuff through JDBC, and access
> data afterwards off the ResultSet, that's a cache. If I convert that
> ResultSet to a collection of objects, and access data in that collection
> afterwards, that's a cache.
>
> Insofar as this level of caching is similar to a persistence context,
> which is referred to as Level 1 in JPA, I have no problems thinking of
> it as Level 1 equivalent.

I would define an ORM cache as a cache in the ORM code not a cache
in my code.

Otherwise any ORM would have a cache since the O will be in memory.

>>> As for JPA Level 2, well, that's a decision best approached carefully
>>> and not made available by default. I surely don't think you need to go
>>> with JPA just in case you might need Level 2 cache at some point.
>>
>> If it was just that: no. But there are other features that also could
>> become useful.
>
> Hopefully you know what you need early on, considering as how you did
> good requirements analysis. In which case you're using JPA because you
> already know you need it.

I don't think I have ever seen requirements that actually covered
all requirements for the actual lifetime of the application.

Arne

On 12-05-03 05:58 PM, Arne Vajhøj wrote:
> On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
>> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>>> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
[ SNIP ]

>>>>> And some of the capabilities (like caching) could become
>>>>> very handy in the future.
>>>>
>>>> The operative word being "could". Leaving aside the other management
>>>> capabilities of the persistence context Level 1 cache, like uniqueness
>>>> of identity within a PC, if you are constructing objects with a simple
>>>> mapper like DBUtils you *have* a cache. Your objects are in memory;
>>>> you're not hitting the DB every time you need them.
>>>
>>> That is not really level 1 cache.
>>
>> What do you consider to be a cache? A cache means that you've got your
>> stuff in a storage area that's faster to access than the original
>> location. Usually memory. If I get my stuff through JDBC, and access
>> data afterwards off the ResultSet, that's a cache. If I convert that
>> ResultSet to a collection of objects, and access data in that collection
>> afterwards, that's a cache.
>>
>> Insofar as this level of caching is similar to a persistence context,
>> which is referred to as Level 1 in JPA, I have no problems thinking of
>> it as Level 1 equivalent.
>
> I would define an ORM cache as a cache in the ORM code not a cache
> in my code.
>
> Otherwise any ORM would have a cache since the O will be in memory.

Fair enough. I pretty much figured that's what you were getting at.
Still, when looking at all the cache offerings out there it's worth
recalling from time to time what they really do.

>>>> As for JPA Level 2, well, that's a decision best approached carefully
>>>> and not made available by default. I surely don't think you need to go
>>>> with JPA just in case you might need Level 2 cache at some point.
>>>
>>> If it was just that: no. But there are other features that also could
>>> become useful.
>>
>> Hopefully you know what you need early on, considering as how you did
>> good requirements analysis. In which case you're using JPA because you
>> already know you need it.
>
> I don't think I have ever seen requirements that actually covered
> all requirements for the actual lifetime of the application.
>
> Arne
>
Nor have I. Although I contend that you should understand your
persistence requirements well enough to know whether JPA is called for.
In fact it's almost always a safe bet; you pretty much need some
concrete reasons *not* to use it [1]. IMO.

AHS

1. Maybe you're writing a JPA implementation, say.
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

On 5/3/2012 5:25 PM, Arved Sandstrom wrote:
> On 12-05-03 05:58 PM, Arne Vajhøj wrote:
>> On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
>>> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>>>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>>>> As for JPA Level 2, well, that's a decision best approached carefully
>>>>> and not made available by default. I surely don't think you need to go
>>>>> with JPA just in case you might need Level 2 cache at some point.
>>>>
>>>> If it was just that: no. But there are other features that also could
>>>> become useful.
>>>
>>> Hopefully you know what you need early on, considering as how you did
>>> good requirements analysis. In which case you're using JPA because you
>>> already know you need it.
>>
>> I don't think I have ever seen requirements that actually covered
>> all requirements for the actual lifetime of the application.
>>
> Nor have I. Although I contend that you should understand your
> persistence requirements well enough to know whether JPA is called for.
> In fact it's almost always a safe bet; you pretty much need some
> concrete reasons *not* to use it [1]. IMO.

I think we are in violent agreement now.

> 1. Maybe you're writing a JPA implementation, say.



Arne