| Re: ORMs comparisons/complaints. [message #184472 is a reply to message #184463] |
Thu, 02 January 2014 17:36   |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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/Marshalling_(computer_science)
Just a thought.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184475 is a reply to message #184472] |
Thu, 02 January 2014 20:06 |
Silvio
Messages: 5
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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/Marshalling_(computer_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.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184476 is a reply to message #184441] |
Thu, 02 January 2014 21:37 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184479 is a reply to message #184461] |
Fri, 03 January 2014 01:43 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 1/2/2014 3:34 AM, Gordon Levi wrote:
> Arne Vajhøj <arne(at)vajhoej(dot)dk> 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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184480 is a reply to message #184460] |
Fri, 03 January 2014 01:54 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184481 is a reply to message #184463] |
Fri, 03 January 2014 01:59 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184482 is a reply to message #184463] |
Fri, 03 January 2014 02:07 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184483 is a reply to message #184463] |
Fri, 03 January 2014 02:10 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184484 is a reply to message #184479] |
Fri, 03 January 2014 09:19 |
Gordon Levi
Messages: 2
Registered: January 2014
Karma: 0
|
Junior Member |
|
|
Arne Vajhøj <arne(at)vajhoej(dot)dk> wrote:
> On 1/2/2014 3:34 AM, Gordon Levi wrote:
>> Arne Vajhøj <arne(at)vajhoej(dot)dk> 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.
Thank you, it seems my fears are well founded. Does that mean that
real Java programmers go to the trouble of breaking the relational
model in order to maintain the object model?
>
> If you are not using an ORM you need to write code to do the
> database interface.
>
> Arne
>
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184497 is a reply to message #184480] |
Fri, 03 January 2014 13:18 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 01/02/2014 09:54 PM, Arne Vajhøj wrote:
> 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
>
Every time I look at the JPA criteria API, I cringe. :-) This
occasionally causes me to use excessive comparisons.
But I don't see how syntax of data access code is not _quite_ important.
Whether SQL or JDBC or JPA or native ORMs etc. Syntax is a major part of
what makes an API readily useable.
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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184499 is a reply to message #184475] |
Fri, 03 January 2014 14:48 |
Chris Uppal
Messages: 2
Registered: January 2014
Karma: 0
|
Junior Member |
|
|
Silvio wrote:
> I tend to liberally use the term serialization
> when I am actually talking about persisting objects.
FWIW, the term "persistence" has been around (in that sense) for /ages/ (See
"PS-Algol" for instance), but the term "serialize" (again, in the relevant
sense) was introduced, as far as I know, by Java[*].
-- chris
[*] and was a bad mistake, IMO, since "serialize" already had another techical
meaing (with no alternative terms in common use) that was /directy/ relevant to
Java too :-(
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184507 is a reply to message #184484] |
Fri, 03 January 2014 20:43 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 1/3/2014 4:19 AM, Gordon Levi wrote:
> Arne Vajhøj <arne(at)vajhoej(dot)dk> wrote:
>
>> On 1/2/2014 3:34 AM, Gordon Levi wrote:
>>> Arne Vajhøj <arne(at)vajhoej(dot)dk> 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.
>
> Thank you, it seems my fears are well founded. Does that mean that
> real Java programmers go to the trouble of breaking the relational
> model in order to maintain the object model?
????
If you use an object oriented language and a relational
database, then you will have both an object model and a
relational model.
Neither model need to be broken.
And it is not something special for Java.
The only thing special for Java may be that using an ORM instead
of a lot of handwritten code when moving data between the two models
is much more common than in many other languages.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184508 is a reply to message #184497] |
Fri, 03 January 2014 21:45 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 1/3/2014 8:18 AM, Arved Sandstrom wrote:
> On 01/02/2014 09:54 PM, Arne Vajhøj wrote:
>> 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.
> Every time I look at the JPA criteria API, I cringe. :-) This
> occasionally causes me to use excessive comparisons.
>
> But I don't see how syntax of data access code is not _quite_ important.
> Whether SQL or JDBC or JPA or native ORMs etc. Syntax is a major part of
> what makes an API readily useable.
It certainly is important.
Arne
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]