Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > ORMs comparisons/complaints.

Reply
Thread Tools

ORMs comparisons/complaints.

 
 
Silvio
Guest
Posts: n/a
 
      01-02-2014
On 01/02/2014 06:36 PM, Daniel Pitts wrote:
> On 1/2/14 3:36 AM, Silvio wrote:
>> On 01/02/2014 04:19 AM, Arne Vajh°j wrote:
>>> On 12/30/2013 8:38 AM, Silvio wrote:
>>>> On 12/30/2013 05:27 AM, Arne Vajh°j wrote:
>>>>> On 12/23/2013 7:25 AM, Silvio wrote:
>>>>> Most places they are actually able to get ORM working.
>>>>>
>>>>> I am not quite sure that I can follow you.
>>>>>
>>>>> If you want OO for the code and you want the relational database,
>>>>> then you must do a mapping between the two.
>>>>>
>>>>> You can either hand write a lot of code or use an ORM.
>>>>>
>>>>> Typical using an ORM is faster because it means less code.
>>>>>
>>>>> You may not be able to use ORM 100%, but then use it 90% and
>>>>> hand write code for the remaining 10%.
>>>>
>>>> ORMs are good at what they where invented for: serializing an object
>>>> and
>>>> resurrecting it at a later point in time.
>>>
>>> Storing objects in a relational database via ORM is very different
>>> from serialization (for non-trivial usage).
>>>
>>> A serialization stores everything in a sequential stream of data.
>>>
>>> Storing objects in a relational database via ORM store the stuff
>>> not already stored in different tables.
>>>
>>> Using a document store have some similarities with serialization.
>>>

>>
>> I meant serialization in the more general sense. I am not talking about
>> Object(In/Out)putStream but about saving the exact state of an instance
>> to some addressable storage with the main purpose of restoring its state
>> later.

>
> Serialization literally means to put an object into a serial form. I
> think you're trying to use it to mean something close to marshalling.
>
> http://en.wikipedia.org/wiki/Marshal...mputer_science)
>
> Just a thought.


Well, I think you are right although the page you link to mentions both
terms as being similar. I tend to liberally use the term serialization
when I am actually talking about persisting objects.


 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-02-2014
On 12/31/2013 09:33 PM, jebblue wrote:
> On Tue, 31 Dec 2013 17:54:12 -0400, Arved Sandstrom wrote:
>
>> On 12/31/2013 12:52 PM, jebblue wrote:
>>> On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
>>>
>>>> I find that I often stretch systems to there
>>>> limits
>>>
>>> It should be their not there.
>>>
>>> ORM's are great to get something fairly simple of the ground
>>> fairly fast. From then on any meaningful feature updates
>>> that requires work in the data layer makes using an ORM
>>> a real PITA.
>>>
>>> Things like, slow performance, hassles when trying to relate
>>> data between tables, trying to sort out what I want the
>>> SQL to do then all the time it takes to sort out all the
>>> ORM annotations and code and test to satisfy the ORM makes
>>> using the ORM a maintenance headache.
>>>
>>> It's a slower coding startup to use straight JDBC but over
>>> time maintenance time and difficulty are linear conststant
>>> with using straight JDBC. Performance is always at a
>>> maximum too.
>>>
>>> So when I can, I avoid ORMs completely.
>>>

>> Have you worked in the programming industry for more than say 5 years?

>
> 20 years, over 30 including Hobbyist
>

[ SNIP ]

Most of the guys that design and implement ORMs actually - oddly enough
- also understand performance. Just about all the time if you're having
a performance problem with an ORM it's because you didn't know what you
were doing. Don't feel bad: I've screwed up a few times too. I've not
met many programmers who had 20 or so years of professional experience,
that didn't have the chops to make them work, unless they simply hadn't
ever used ORMs much...which is OK.

Hassles when trying to relate data between tables? You mean more so than
trying to do that with JDBC or SQL?

AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
 
 
 
Arne Vajh├Şj
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 3:04 AM, Arved Sandstrom wrote:
> By the way, my man, my youngest uncle was also called Arne. Happy NY.


The name is not unusual in Scandinavia. Just did a lookup - we are
13805 Arne in Denmark alone.

Happy NY to you too.

Arne


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 3:34 AM, Gordon Levi wrote:
> Arne Vajh°j <(E-Mail Removed)> wrote:
>> Let us say that you need to add a field.
>>
>> With an ORM you only need to update:
>> * one dataclass
>> * one mapping of data
>>
>> With plain JDBC you need to change:
>> * one data class
>> * N SQL statements
>> * N places in the Java code

>
> I don't understand this so I fear I must be doing something wrong in
> my Java programs. If someone wants to add a field in a database why do
> I have to alter anything in my program other than adding, for example,
> getString(String columnLabel) if I want to actually use the new field
> at that point in the program.


The context is that the class is persisted in a relational
database.

If you are not using an ORM you need to write code to do the
database interface.

Arne


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 3:09 AM, Arved Sandstrom wrote:
> On 01/01/2014 10:54 PM, Arne Vajh°j wrote:
>> On 12/30/2013 4:36 PM, Arved Sandstrom wrote:
>>> I'll say this: Java language limitations have hurt Java ORMs, and it's
>>> not the fault of the ORM developers: I know a few of them. The JPA
>>> Criteria API is a sign of the apocalypse. It's unfortunately informed by
>>> folks who are both struggling with Java limitations and have experience
>>> with native implementations. C# LINQ and Scala Squeryl are conceptually
>>> light years ahead of Java ORMs.

>>
>> Much cleaner syntax.
>>
>> But I am not convinced that the syntax is sufficient important
>> to translate that into "light years ahead".
>>

> We can agree to disagree, Arne. I think ideas like C# LINQ and Scala
> Squeryl are far in advance of Java.
>
> I was able to write a Scala DSL a few years ago that would not have been
> possible in Java. Similarly, C# - I think you'd have to admit - is quite
> far ahead of Java.


I think we almost agree on the grading of the syntaxes.

But we may disagree on the weight given to syntax in an ORM
evaluation.

I just don't see syntax for queries as being important enough
to cause "light years ahead".

Everything else equal, then a nice syntax obviously create
a winner.

Arne

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 6:36 AM, Silvio wrote:
> On 01/02/2014 04:19 AM, Arne Vajh°j wrote:
>> On 12/30/2013 8:38 AM, Silvio wrote:
>>> On 12/30/2013 05:27 AM, Arne Vajh°j wrote:
>>>> On 12/23/2013 7:25 AM, Silvio wrote:
>>>> Most places they are actually able to get ORM working.
>>>>
>>>> I am not quite sure that I can follow you.
>>>>
>>>> If you want OO for the code and you want the relational database,
>>>> then you must do a mapping between the two.
>>>>
>>>> You can either hand write a lot of code or use an ORM.
>>>>
>>>> Typical using an ORM is faster because it means less code.
>>>>
>>>> You may not be able to use ORM 100%, but then use it 90% and
>>>> hand write code for the remaining 10%.
>>>
>>> ORMs are good at what they where invented for: serializing an object and
>>> resurrecting it at a later point in time.

>>
>> Storing objects in a relational database via ORM is very different
>> from serialization (for non-trivial usage).
>>
>> A serialization stores everything in a sequential stream of data.
>>
>> Storing objects in a relational database via ORM store the stuff
>> not already stored in different tables.
>>
>> Using a document store have some similarities with serialization.
>>

>
> I meant serialization in the more general sense. I am not talking about
> Object(In/Out)putStream but about saving the exact state of an instance
> to some addressable storage with the main purpose of restoring its state
> later.


That is not the way the term serialization is normally used.

But it is a common requirement for both ORM and plain JDBC.

>>> That means you have to design
>>> your system and its underlying data as a collection of objects with
>>> (encapsulated) member data. Using that approach the lifetime of an
>>> object instance must be able to extend the actual running span of the
>>> program. That requires serialization/resurrection by definition.

>>
>> No.
>>
>> It requires the ability to save and load data.

>
> No, not data but instances. My point is that these are fundamentally
> different.


Not really.

A data class as typical used by ORM's does contain data as the term
"data class" implies.

Arne

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 6:36 AM, Silvio wrote:
> On 01/02/2014 04:19 AM, Arne Vajh°j wrote:
>> On 12/30/2013 8:38 AM, Silvio wrote:
>>> Apart
>>> from the fact that I think that this is a bad approach on its own, to
>>> constrain memory usage objects need to be put to sleep by default and be
>>> resurrected only when they are accessed.

>>
>> That is how persistence works. The data are on disk and when a program
>> needs them they are read from disk to memory.
>>
>>> This makes the approach even
>>> more blurred and needlessly complex, bringing stuff like caching and
>>> managing/synchronizing duplicate object instances across concurrently
>>> running program instances into the picture.

>>
>> But that is not in any way ORM specific.
>>
>> Plain JDBC will have the same potential issues with caching.

>
> In theory the ORM approach does not need more caching than a RDBMS
> driven approach. In practice this is not the case.


????

Some ORM's come without what at least in the Java world is known
as level 2 cache (cache of data outside of ongoing transaction).

But for those with level 2 cache, then I have never seen one
where it could not be disabled.

If you don't want it, then just turn it of.

> The number of cases
> where caching outside of the RDBMS is actually needed is very limited
> and I rarely use any form of data caching.


????

Use of cache is essential for achieving good performance for many many
types of application no matter language, database or database access
technology.

> Without exception all the ORM systems I worked on relied heavily on
> caching or the would not be practically usable.


I don't know what ORM's you have worked with.

But the ORM's create the same SQL as handwritten SQL, so there are
no more and no less need for caching.

Furthermore among some of the most popular ORM's then level 2 cache is
either disabled by default (Hibernate) or not existing (EF).

>>> To make things worse almost no system only needs single object
>>> instances. Almost any practical system needs counts, averages etc. which
>>> could be done with a query on an RDBMS or by traversing object instances
>>> IF THEY WHERE REAL INSTANCES. Since doing the latter with an ORM would
>>> require resurrecting enormous amounts of instances for practical reasons
>>> you have to pour water into the wine and do atypical stuff like joins
>>> and aggregate queries through the ORM.

>>
>> ????
>>
>> Joins is a core feature of an ORM.

>
> You can do joins easily but that is not the big problem. The core
> problem is that joins create new views on the underlying data that do
> not match with the entity classes that match its underlying tables. To
> represent the data from a join properly you would need a new class and
> then you get into one of the biggest culprits with ORM: aliased data and
> cache redundancy.


????

Any decent ORM just do the joins, load the data and no aliased data
(beyond where required due to data actually being the same also in the
database).

Arne

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-03-2014
On 1/2/2014 6:36 AM, Silvio wrote:
> On 01/02/2014 04:19 AM, Arne Vajh°j wrote:
>> On 12/30/2013 8:38 AM, Silvio wrote:
>>> This is also the area where ORMs failed in the projects
>>> I talked about. It's not that the ORM can not do it, it just can not do
>>> it sufficiently well even with help from the most experienced experts we
>>> could find.

>>
>> ????
>>
>> Joins is a core feature of ORM.
>>
>> And common Java ORM's like JPA implemntations and Hibernate does
>> aggregate functions exactly like SQL in JPQL and HQL respectively.
>>
>> I wonder what kind of "experts" you got.

>
> Yes, they got all the stuff working the first time with joins and
> aggregates like you say. But after some time they got into trouble
> because aliased data caused the systems to show faulty counts and totals
> etc. and from there on it went down-hill. On more than one system they
> had to forcefully flush the cache at specific moments to get the right
> results for subsequent reporting. Which then did not work very promptly,
> to put it mildly.


It has either been a horrible ORM or some horrible "experts".

> Most systems I work(ed) on are primarily analytical systems working on
> data that comes from surveys, measure devices, order tracking systems
> etc. and fetching a record and storing it after manually changing some
> attributes is not the common use case. The primary goal is to properly
> manage such data at the record level behind the scenes while at the same
> time allow thorough analysis of the overall process. Much of this
> requires aggregates on joins that have to be built dynamically because
> the user can specify exactly what he needs via a UI, akin to an OLAP
> system.
>
> I admit that this is not a good match for ORM but in these cases that
> was hindsight wisdom. When they started they thought ORM was the right
> tool. Which does not surprise me since I encounter many people who never
> doubt ORM is the way to go with any system.


Ah.

ORM's are often good for transactional data (OLTP).

Not as obvious a choice for analytical data (DWH).

Arne


 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-03-2014
On 01/02/2014 06:02 AM, lipska the kat wrote:
> On 02/01/14 08:34, Gordon Levi wrote:
>> Arne Vajh°j <(E-Mail Removed)> wrote:
>>
>>> Let us say that you need to add a field.
>>>
>>> With an ORM you only need to update:
>>> * one dataclass
>>> * one mapping of data
>>>
>>> With plain JDBC you need to change:
>>> * one data class
>>> * N SQL statements
>>> * N places in the Java code

>>
>> I don't understand this so I fear I must be doing something wrong in
>> my Java programs. If someone wants to add a field in a database why do
>> I have to alter anything in my program other than adding, for example,
>> getString(String columnLabel) if I want to actually use the new field
>> at that point in the program.

>
> Well I'm not sure what kind of Java applications you write but in the
> world I inhabit the client request "we just want to add one more field
> to this form" is guaranteed to send a shiver down the spine as it's
> usually followed by "How much?, for adding a single field? you gotta be
> kidding".


Most BA, end user, customer, and PM requests send shivers down
developers' spines.

> To add a single persisted field to an input form requires the
> modification of most if not all of the layers of an application.


If it's actually a persisted field in an input form (various types of
data input mechanisms related to or from HTML, MS, Oracle, Adobe, IBM,
etc), I agree. That by definition affects _every_ layer.

> Adding a single field to a product line for example would probably
> require the modification of all the CRUD methods for that line, not to
> mention the inclusion of the field in the search algorithms, modifying
> the validation layer, incorporating the field in a logical place in the
> HCI, modifying and refactoring the relevant code etc etc. Anything that
> can reduce the amount of work required to implement such an apparently
> trivial change has got to be a good idea.


From the implementation standpoint a persisted field addition, deletion
or modification, in a complete stack scenario, will consume at least a
man-day, and possibly several. It really won't make much of a difference
as to whether a Java ORM or JDBC is involved...not on average.

The actual problem with changes of this sort is that someone a bit
higher up than the grunt coder altered the requirements, or the design.
Proponents of agile have bent over backwards to accommodate these
ineffiencies: this is just letting non-technological people dictate
implementation.

> Having said that, I don't used ORMs myself, I mean I've tried, I've
> really tried but I start reading the documentation and my eyes glaze
> over and I discover that I need to learn 'another' (query) language and
> I decide that it's just not worth the effort. Stick to SQL, accept the
> overhead and I don't think you can go far wrong.
>
> Just my 2 euros worth
>


The JPA specs are some of the best specs I've seen. The associated specs
for the actual implementations are also quite good. If your eyes are
glazing over when you try to read these, I'm pretty sure you've got a
hell of a time with almost every other spec out there.

Feel free to stick to SQL and waste substantial time doing NIH. It could
just be me, but I like it when I get a substantial assist creating
objects out of relational data. You just now above said "accept the
overhead": guess what, there's a lot of overhead.

AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-03-2014
On 01/02/2014 05:00 PM, Martin Gregorie wrote:
> On Thu, 02 Jan 2014 03:57:27 -0400, Arved Sandstrom wrote:
>
>> Not entirely sure what you mean here, Marcel. In all seriousness I don't
>> think I've ever seen anyone normalize or selectively denormalize a data
>> model at "object level". Apart from that, I'm not quite sure how one
>> would conveniently normalize data at the object level (presumably
>> through the ORM) if the data showed up denormalized.
>>

> Does he mean near-exclusive use of 3NF?
>
> On the occasions when I've stopped at 2NF where the database or 4GL
> supports that and/or thrown a few derived fields such as account totals
> etc. into the data model. I've usually regretted it.
>
> I seldom find myself mapping data model entities 1:1 onto objects for two
> reasons: firstly, because after spending quite a bit of time as a DB
> designer/tuner/developer and writing a fair bit of SQL in the process I
> tend to think in terms of using JDBC rather than a JPA and partly because
> about the only times I've needed to handle arrays of objects that
> represent entities they've ended up as components of an object
> representing an ordered collection of the components, e.g. the collection
> of GPS fixes representing a flight path. In these cases, and individual
> component is of relatively little interest because you want to display or
> analyze the collection as a whole and/or its an intermediate data store
> used as part of transforming the collection from one external
> representation to another.
>

One of the sweetest things to me about JPA is constructor expressions. I
actually have met a few of the guys who came up with this: if there is
one concept in JPA that recognizes practical needs, and doesn't get too
theoretical, it's this one. It's much better, IMO, than the plethora of
other JPA techniques for producing objects.

You're not the first person in this thread who referred to object
collections or aggregate values. I've not myself found straight SQL or
JDBC any better than JPA for doing this stuff: if your app is Java then
you ultimately need to translate into objects, and often object
collections. I don't care to continually write that boilerplate myself.

AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python ORMs Supporting POPOs and Substituting Layers in Django Travis Parks Python 10 11-12-2011 04:11 PM
Working with databases (ODBC and ORMs) in Python 3.2 tkpmep@hotmail.com Python 1 11-10-2011 08:35 PM
ORMs for applications written in C gvk C Programming 1 01-09-2011 07:24 AM
Re: ORMs for applications written in C gvk C Programming 2 01-08-2011 10:06 PM
Limitations of all Ruby ORMs Alexey Petrushin Ruby 3 06-16-2009 07:21 AM



Advertisments