Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #27043 > unrolled thread
| Started by | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| First post | 2013-12-22 11:05 -0800 |
| Last post | 2014-01-03 15:43 -0500 |
| Articles | 20 on this page of 163 — 27 participants |
Back to article view | Back to comp.lang.java.programmer
ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-12-22 11:05 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 14:46 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 15:17 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 15:38 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 15:47 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 16:04 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 16:09 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 16:20 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 16:34 -0500
Re: ORMs comparisons/complaints. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-12-22 22:45 +0100
Re: ORMs comparisons/complaints. markspace <markspace@nospam.nospam> - 2013-12-22 17:33 -0800
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-23 12:54 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 22:34 -0500
Re: ORMs comparisons/complaints. Wanja Gayk <brixomatic@yahoo.com> - 2013-12-24 12:28 +0100
c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-24 08:49 -0500
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 09:35 +1100
Re: c Graham Hobbs <ghobbs@cdpwise.net> - 2013-12-24 19:35 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-25 00:08 -0500
Re: c lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-25 09:07 +0000
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 20:41 +1100
[EOD] Re: c Wanja Gayk <brixomatic@yahoo.com> - 2013-12-25 11:15 +0100
Re: [EOD] Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 23:29 +1100
Re: [EOD] Re: c The Natural Philosopher <tnp@invalid.invalid> - 2013-12-25 12:48 +0000
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 17:46 +1100
Re: c Graham Hobbs <ghobbs@cdpwise.net> - 2013-12-25 09:24 -0500
Re: c Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 22:51 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 08:03 -0500
Re: c Arne Vajhøj <arne@vajhoej.dk> - 2013-12-30 12:40 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 12:46 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 22:48 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-23 17:38 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-23 07:57 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-24 10:11 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-23 19:59 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-24 12:14 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:02 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 15:40 +1100
Re: ORMs comparisons/complaints. Michael Vilain <vilain@NOspamcop.net> - 2013-12-22 20:48 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 22:46 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 14:54 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:06 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 15:21 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 08:04 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-30 12:32 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 12:47 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-31 08:23 +1100
Re: ORMs comparisons/complaints. Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-12-30 19:45 +0000
Re: ORMs comparisons/complaints. Ricardo Palomaes <rpmdisguise-java@nowhere.com> - 2013-12-30 19:20 +0100
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-30 18:34 +0000
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 14:27 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-22 22:26 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:17 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-31 11:12 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 21:35 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2014-01-06 22:19 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-07 23:33 -0400
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-08 00:37 -0600
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 17:03 -0400
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-31 15:30 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 03:57 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-02 21:00 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 01:34 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 21:56 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-04 01:15 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 14:45 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-05 03:59 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-05 15:51 -0500
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-05 23:53 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-05 20:00 -0500
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:38 +0000
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:41 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 12:27 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 18:49 -0400
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:39 +0000
Re: ORMs comparisons/complaints. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-12-22 16:11 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:08 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 17:36 -0400
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-30 22:13 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 22:09 -0400
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-31 11:30 +0000
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-31 08:11 -0500
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-01 14:20 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:05 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-01-02 14:48 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:57 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 04:04 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:39 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 09:10 -0400
Re: ORMs comparisons/complaints. Lars Enderin <lars.enderin@telia.com> - 2014-01-03 20:10 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 18:34 -0400
Re: ORMs comparisons/complaints. Lars Enderin <lars.enderin@telia.com> - 2014-01-04 07:02 +0100
Re: ORMs comparisons/complaints. Joerg Meier <joergmmeier@arcor.de> - 2014-01-04 14:12 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 13:53 -0500
Re: ORMs comparisons/complaints. Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-01-08 11:48 +0200
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-08 14:27 -0400
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-04 17:17 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:54 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 04:09 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:54 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 09:18 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:45 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-23 13:25 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:27 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-30 14:38 +0100
Re: ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-12-30 09:36 -0800
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-31 01:26 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:23 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:19 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2014-01-02 12:36 +0100
Re: ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-01-02 09:36 -0800
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2014-01-02 21:06 +0100
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 14:48 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:59 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 21:07 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 21:10 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-31 09:44 -0400
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2013-12-23 07:22 -0600
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:20 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-25 13:56 -0400
Re: ORMs comparisons/complaints. jebblue <n@n.nnn> - 2013-12-31 10:52 -0600
Re: ORMs comparisons/complaints. Evan Platt <evan@theobvious.espphotography.com.invalid> - 2013-12-31 11:50 -0800
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-31 17:54 -0400
Re: ORMs comparisons/complaints. jebblue <n@n.nnn> - 2013-12-31 19:33 -0600
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 17:37 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:46 -0500
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-02 19:34 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-02 10:02 +0000
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-01-02 23:09 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-02 12:22 +0000
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-03 20:06 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:17 +0000
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-04 00:41 +1100
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-03 06:41 -0600
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 14:56 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 12:12 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-03 19:30 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 16:04 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-03 22:30 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-05 23:44 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:28 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:08 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 16:22 -0400
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 00:29 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:08 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 10:18 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 15:24 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 17:10 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-04 10:02 +0000
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-04 16:02 +0000
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-04 17:27 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 12:46 -0500
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-04 19:51 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 19:24 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 14:08 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:39 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:43 -0500
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-03 20:19 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:23 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 11:34 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 15:58 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:01 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 17:44 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 15:43 -0500
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 16:45 -0500 |
| Message-ID | <52c72f93$0$298$14726298@news.sunsite.dk> |
| In reply to | #27196 |
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
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2013-12-23 13:25 +0100 |
| Message-ID | <52b82ba8$0$2874$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27043 |
I did several stabs at ORMs in some small toy projects but have mainly use ORMs working on existing projects using ORMs (both Hibernate and Toplink) that where performing extremely poorly and had become almost impossible to maintain and extend. I was then called in to take the ORM out of the system as much as possible. This always consisted of creating alternative tools for interacting with the RDBMS that the programmers could use to rewrite the must critical and/or problematic system parts. So you could say I have mainly negative experiences I could share. To put it bluntly: I think ORM is a bad idea in general. I dig OOP for modelling the transient behaviour of a running program but find the relational model far superior for modelling data. I also find it beneficial in general to think of data and programs working on data as separate things. ORM is a mechanism to help you do it the other way around, and a poor one at it. If you want to persist objects use an object database or serialize to some NoSQL store. If you want structured data in an RDBMS don't degrade it into a pile of persisted objects. Silvio
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-29 23:27 -0500 |
| Message-ID | <52c0f626$0$298$14726298@news.sunsite.dk> |
| In reply to | #27063 |
On 12/23/2013 7:25 AM, Silvio wrote: > I did several stabs at ORMs in some small toy projects but have mainly > use ORMs working on existing projects using ORMs (both Hibernate and > Toplink) that where performing extremely poorly and had become almost > impossible to maintain and extend. I was then called in to take the ORM > out of the system as much as possible. This always consisted of creating > alternative tools for interacting with the RDBMS that the programmers > could use to rewrite the must critical and/or problematic system parts. Most places they are actually able to get ORM working. > So you could say I have mainly negative experiences I could share. To > put it bluntly: I think ORM is a bad idea in general. I dig OOP for > modelling the transient behaviour of a running program but find the > relational model far superior for modelling data. I also find it > beneficial in general to think of data and programs working on data as > separate things. > > ORM is a mechanism to help you do it the other way around, and a poor > one at it. If you want to persist objects use an object database or > serialize to some NoSQL store. If you want structured data in an RDBMS > don't degrade it into a pile of persisted objects. 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%. Arne
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2013-12-30 14:38 +0100 |
| Message-ID | <52c1776d$0$2832$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27114 |
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%. > > Arne > ORMs are good at what they where invented for: serializing an object and resurrecting it at a later point in time. 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. 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. 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. 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. I know they CAN do this but that is no more than a wart on such systems since they contradict the primary goal of an ORM. 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. I still think the best approach for most systems is to design a separate and independent data store that covers the problem domain which is completely isolated from the systems that implement data extractions, processes and data storage. I do not manually write code to serialize object instances since I do not serialize them in the first place. Such a data store can be an RDBMS but if so desired a NoSQL thingy or even a file system could do well. Using an RDBMS gives the additional advantage that the data is readily accessible for standard reporting and ETL tools.
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2013-12-30 09:36 -0800 |
| Message-ID | <saiwu.109556$DB4.107916@fx14.iad> |
| In reply to | #27118 |
On 12/30/13 5:38 AM, Silvio wrote: [snip] > 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. I know they CAN do this but that > is no more than a wart on such systems since they contradict the primary > goal of an ORM. 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. This is a good point, and it was something niggling in subconscious. This is where I've always struggled with ORMs, but I never consciously acknowledged that the difficulty was in utilizing the power of the "R" in The ORM. > > I still think the best approach for most systems is to design a separate > and independent data store that covers the problem domain which is > completely isolated from the systems that implement data extractions, > processes and data storage. I do not manually write code to serialize > object instances since I do not serialize them in the first place. Such > a data store can be an RDBMS but if so desired a NoSQL thingy or even a > file system could do well. Using an RDBMS gives the additional advantage > that the data is readily accessible for standard reporting and ETL tools. This is one approach. I think one of the major "features" of most ORM implementations is that they attempt to abstract away the actual RDBMS layer to the point where you feel "dirty" trying to access it in any meaningful way. This does provide some value in portability, but many applications rarely need this portability of RDBMS, and more often benefit from special features of the particular RDBMS chosen. I once actually had to "extend" (read hack) Hibernate to allow the "group_concat" MySQL call in an HQL query.
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2013-12-31 01:26 +0100 |
| Message-ID | <52c20f32$0$2928$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27121 |
On 12/30/2013 06:36 PM, Daniel Pitts wrote: > [snip] > This is one approach. I think one of the major "features" of most ORM > implementations is that they attempt to abstract away the actual RDBMS > layer to the point where you feel "dirty" trying to access it in any > meaningful way. This does provide some value in portability, but many > applications rarely need this portability of RDBMS, and more often > benefit from special features of the particular RDBMS chosen. Portability across RDBMS-es is far more often planned for upfront than it is actually used. But if it is really desired it can easily be achieved in the data access layers. Not exactly rocket science, I have done it in many systems. Treating the data store as a separate deliverable gives a much more important type of flexibility: being able too swap out (parts of) applications that access the data since their interaction with that data is well defined instead of an implicit artifact of the applications themselves.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-01 22:23 -0500 |
| Message-ID | <52c4dbad$0$304$14726298@news.sunsite.dk> |
| In reply to | #27121 |
On 12/30/2013 12:36 PM, Daniel Pitts wrote: > On 12/30/13 5:38 AM, Silvio wrote: > [snip] >> 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. I know they CAN do this but that >> is no more than a wart on such systems since they contradict the primary >> goal of an ORM. 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. > This is a good point, and it was something niggling in subconscious. > This is where I've always struggled with ORMs, but I never consciously > acknowledged that the difficulty was in utilizing the power of the "R" > in The ORM. > >> I still think the best approach for most systems is to design a separate >> and independent data store that covers the problem domain which is >> completely isolated from the systems that implement data extractions, >> processes and data storage. I do not manually write code to serialize >> object instances since I do not serialize them in the first place. Such >> a data store can be an RDBMS but if so desired a NoSQL thingy or even a >> file system could do well. Using an RDBMS gives the additional advantage >> that the data is readily accessible for standard reporting and ETL tools. > This is one approach. I think one of the major "features" of most ORM > implementations is that they attempt to abstract away the actual RDBMS > layer to the point where you feel "dirty" trying to access it in any > meaningful way. This does provide some value in portability, but many > applications rarely need this portability of RDBMS, and more often > benefit from special features of the particular RDBMS chosen. Plain JDBC code can be written rather portable as well *within* the area where ORM actually makes sense, so I agree that portability is not the big argument for ORM. To me the advantage of using an ORM is simply all the code you don't have to write. Regarding getting away from the relational database, then note that common Java ORM's like JPA implementations and Hibernate actually allows you to use SQL queries. It is not strongly typed, but the capability is there. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-01 22:19 -0500 |
| Message-ID | <52c4dabe$0$304$14726298@news.sunsite.dk> |
| In reply to | #27118 |
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. > 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. > 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. > 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. > I know they CAN do this but that > is no more than a wart on such systems since they contradict the primary > goal of an ORM. Aggregate functions are not very ORM'ish. But if they are used much in the transactional work that ORM is intended, then something is wrong in the first place. > 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. Arne
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2014-01-02 12:36 +0100 |
| Message-ID | <52c54f4e$0$2965$e4fe514c@news.xs4all.nl> |
| In reply to | #27163 |
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 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. >> 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. 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. Without exception all the ORM systems I worked on relied heavily on caching or the would not be practically usable. >> 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. >> I know they CAN do this but that >> is no more than a wart on such systems since they contradict the primary >> goal of an ORM. > > Aggregate functions are not very ORM'ish. > > But if they are used much in the transactional work that ORM > is intended, then something is wrong in the first place. > That is just my point. I never encounter any purely transactional system. That is almost always a part but it is always the easy part. Also, it's not that ORM tool providers shout from the roofs that you should only use them for transactional stuff... >> 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. > > Arne > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2014-01-02 09:36 -0800 |
| Message-ID | <mshxu.172505$Uv.65753@fx30.iad> |
| In reply to | #27172 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2014-01-02 21:06 +0100 |
| Message-ID | <52c5c6c9$0$2868$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27175 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2014-01-03 14:48 +0000 |
| Message-ID | <Rd-dnXFztdWVTVvPnZ2dnUVZ8hednZ2d@bt.com> |
| In reply to | #27176 |
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 :-(
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-02 20:59 -0500 |
| Message-ID | <52c6196c$0$302$14726298@news.sunsite.dk> |
| In reply to | #27172 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-02 21:07 -0500 |
| Message-ID | <52c61b71$0$302$14726298@news.sunsite.dk> |
| In reply to | #27172 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-02 21:10 -0500 |
| Message-ID | <52c61c15$0$302$14726298@news.sunsite.dk> |
| In reply to | #27172 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-31 09:44 -0400 |
| Message-ID | <SSzwu.134475$cZ.128418@fx31.iad> |
| In reply to | #27063 |
On 12/23/2013 08:25 AM, Silvio wrote: > I did several stabs at ORMs in some small toy projects but have mainly > use ORMs working on existing projects using ORMs (both Hibernate and > Toplink) that where performing extremely poorly and had become almost > impossible to maintain and extend. I was then called in to take the ORM > out of the system as much as possible. This always consisted of creating > alternative tools for interacting with the RDBMS that the programmers > could use to rewrite the must critical and/or problematic system parts. > > So you could say I have mainly negative experiences I could share. To > put it bluntly: I think ORM is a bad idea in general. I dig OOP for > modelling the transient behaviour of a running program but find the > relational model far superior for modelling data. I also find it > beneficial in general to think of data and programs working on data as > separate things. > > ORM is a mechanism to help you do it the other way around, and a poor > one at it. If you want to persist objects use an object database or > serialize to some NoSQL store. If you want structured data in an RDBMS > don't degrade it into a pile of persisted objects. > > Silvio I also find the relational model very useful for modeling data: usually better than other models. As I noted in another post, ORMs don't typically distance a programmer that much from relational concepts: they simply hide some of the mechanics. If you want to routinely use JDBC and manually construct objects, feel free - I like having libraries doing some of the heavy lifting. The last sentence of your last para is remarkable. I'd be interested to know why an object (a class instance for class-based OO) is a poor representation of data in a RDBMS. You might as well state that a C struct or a Haskell data type is unsuitable for that purpose. If I want to access structured data in an RDBMS, and I am writing in an OO language (not an uncommon requirement these days), I think I'll use a semblance of an ORM. I'm reluctant to write assembly language to manipulate data...not in 2013. If you had mainly negative experiences with ORMs, Silvio, and I'll take your word for it, then perhaps your colleagues were inept or incompetent or lazy. I've experienced the same problems you described, many times: come to find out that the performance problems were human and needed to be fired. 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
[toc] | [prev] | [next] | [standalone]
| From | leif.roar@invalid.com (Leif Roar Moldskred) |
|---|---|
| Date | 2013-12-23 07:22 -0600 |
| Message-ID | <eamdnX3A_oC_pCXPnZ2dnUVZ8nidnZ2d@giganews.com> |
| In reply to | #27043 |
In comp.lang.java.programmer Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote: > > So, my question to the groups, what ORMs have you used, and what did you > like and hate about each of them? I'm not trying to start a flame war, > so please keep it to personal experiences with projects which used them. I've worked with Hibernate / JPA and plain old SQL, and for my purposes (business/process-driven web applications) they're a wash. Both are painful in their own way, and I can't say I prefer either over the other. Hibernate takes the pain out of managing the differences in SQL dialects between various databases, and makes it quick to map data from the relational tables into your domain objects. On the bad side, you end up with "one view and one view only" of your data -- trying to represent the data in a table in two different ways depending on use is a real pain with Hibernate. You also often end up having to write mapping code for your data _anyway_, as you might want to map your domain objects into transfer objects to keep your database model from leaking out into the display layer or elsewhere. One annoyance with Hibernate is that you can't easily specify how much of your object graph you want a query to cover, so you end up having to keep your database transactions open across the whole of the business process step, as Hibernate doesn't know what to retrieve until it's actually used. Perhaps most dangerously, Hibernate insulates the developers from the database and keeps them from getting necessary understanding and experience with it. You easily end up with developers who has learnt to muddle along using Hibernate, but doesn't really understand what's happening beneath it. That wouldn't be a problem if Hibernate let you do 100% of what you needed to do, but in my experience you usually end up with 5-10% of the database access being ill suited to Hibernate. Plain SQL is a pain because you have to write all your own data mapping code, which is error-prone and end up being more work than you thought -- and then you have to manage all the relationships between data in different tables yourself. The JDBC API is also really, really bad, but you can escape much of that pain by using a helper like JDBC Template or similar. -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-29 23:20 -0500 |
| Message-ID | <52c0f486$0$298$14726298@news.sunsite.dk> |
| In reply to | #27065 |
On 12/23/2013 8:22 AM, Leif Roar Moldskred wrote: > The JDBC API is also really, really bad, but you can escape much of > that pain by using a helper like JDBC Template or similar. JDBC is a low level database API. And it is very similar to ODBC, ADO, ADO.NET, mysqli etc.. I don't think it can be that much different for a low level API. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-25 13:56 -0400 |
| Message-ID | <Z_Euu.79296$PK.43448@fx23.iad> |
| In reply to | #27043 |
On 12/22/2013 03:05 PM, Daniel Pitts wrote: > Hey everyone, > > This is cross-posted to cl.java.programmer and cl.php. > > I've been doing some thinking about my experiences with various ORMs, > both positive and negative. I find that I often stretch systems to > there limits, and end up doing a lot of meta-programming to solve > problems that I've always felt should have been solved by the core > libraries. Mostly to follow DRY and KISS principals in the core > business code. > > I'm curious if others' have found the same things I have, or if they've > been satisfied doing things other ways, and if so what ORMs they use. > > I've had experience with the following Java ORMs: > * Hibernate (version 3, using Annotations for instance) > * Ibatis (many years ago, don't remember the version. around 2006) > * Straight JDBC. Not exactly an ORM :-) > > And then one non-Java ORM: Doctrine, which is modeled after Hibernate, > including most of its flaws, but missing some of its features. > > > So, my question to the groups, what ORMs have you used, and what did you > like and hate about each of them? I'm not trying to start a flame war, > so please keep it to personal experiences with projects which used them. > > I'm interested in use-cases from simple small one-off applications to > complex enterprise-level systems, and highly-scalable systems. > > Please include details like "it's easier to maintain <x> type of changes > with our approach, but <y> is very difficult" etc... > > Thanks for your consideration, > Daniel. Java ORMs: Hibernate - but not recently, and even when I used it last mostly in its first JPA incarnation, and not much. Last use of native Hibernate many years ago; Straight JDBC - still quite a lot. Not an ORM, as you say; iBatis/MyBatis - a fair bit; TopLink/TopLink Essentials (TLE)/EclipseLink - a lot. Native for first two + JPA, JPA through EclipseLink. My ideas about ORMs have been informed a fair bit by using them in other languages, so although I won't blur the issue by mentioning them, their use will influence my opinions. *Industry* use of the various Java ORMs above: native Hibernate a long time ago, Hibernate JPA just a little, native TopLink a long time ago, TLE and EclipseLink a great deal for JPA. Non-ORM: straight JDBC a lot and since it got invented. I prefer JPA as an ORM API. I have no strong thoughts on Hibernate JPA versus EclipseLink JPA...I had to settle on one and chose TLE/EclipseLink. I have investigated JDO - it is more general than JPA insofar as it doesn't require a RDBMS datastore - but no industry projects I've been involved with (in 15 years or more) have been anything but RDBMS. JPA disadvantages (IMHO): relatively high bar to entry...not that simple to use well, and especially now with JPA 2 so many features that a novice can get discombobulated: IOW, not simple. JPA advantages: pretty much the reverse of the immediate above - efficient and powerful if you know what you are doing. "Knowing what you are doing" means not relying on IDEs, understanding lifetimes, and knowing what features you should not usually use. If I had to not use JPA I'd use straight JDBC, and do. 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
[toc] | [prev] | [next] | [standalone]
| From | jebblue <n@n.nnn> |
|---|---|
| Date | 2013-12-31 10:52 -0600 |
| Message-ID | <n_Sdnd5kTfjDa1_PnZ2dnUVZ_hednZ2d@giganews.com> |
| In reply to | #27043 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web