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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Evan Platt <evan@theobvious.espphotography.com.invalid> |
|---|---|
| Date | 2013-12-31 11:50 -0800 |
| Message-ID | <5s76c99vf7kvmlspj4dnq4vp1udlbp18dk@4ax.com> |
| In reply to | #27154 |
On Tue, 31 Dec 2013 10:52:46 -0600, jebblue <n@n.nnn> 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 It should be off not of. >fairly fast. From then on any meaningful feature updates There should be a comma after on. >that requires work in the data layer makes using an ORM >a real PITA. > >Things like, slow performance, hassles when trying to relate There should be no comma after like. >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. My head hurts reading that run on sentence. >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. If you're going to nitpick someone's spelling / grammar, make sure your post is in order :) -- To reply via e-mail, remove The Obvious and .invalid from my e-mail address.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-31 17:54 -0400 |
| Message-ID | <82Hwu.135723$DB4.62783@fx14.iad> |
| In reply to | #27154 |
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? No point you made actually made much sense. I must admit, I've heard a few guys just 3 years out of uni who style themselves as technical architects or senior consultants who opine like this. Your observations wrt JDBC vs use of an ORM are not borne out by experience. A fair few knowledgeable people have decided that Java ORMs make sense: I happen to believe that they are correct - ORMs are complex, and JDBC is more complex, and not very many coders are truly adept at SQL. And "performance is always at a maximum"? JDBC versus ORMs? How so? Just about 99 percent of the people who write Java ORMs are intimately familiar with JDBC and SQL - I happen to know a few of them. I respectfully suggest that if you're having performance problems or can't solve relational calculus, it's not an ORM problem. 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 19:33 -0600 |
| Message-ID | <Da6dnf-5Hf3F7V7PnZ2dnUVZ_smdnZ2d@giganews.com> |
| In reply to | #27156 |
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 > No point you made actually made much sense. I must admit, I've heard a > few guys just 3 years out of uni who style themselves as technical > architects or senior consultants who opine like this. > > Your observations wrt JDBC vs use of an ORM are not borne out by > experience. A fair few knowledgeable people have decided that Java ORMs > make sense: I happen to believe that they are correct - ORMs are > complex, and JDBC is more complex, and not very many coders are truly > adept at SQL. > > And "performance is always at a maximum"? JDBC versus ORMs? How so? Just > about 99 percent of the people who write Java ORMs are intimately > familiar with JDBC and SQL - I happen to know a few of them. I > respectfully suggest that if you're having performance problems or can't > solve relational calculus, it's not an ORM problem. > > AHS
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-02 17:37 -0400 |
| Message-ID | <4_kxu.127957$PK.110228@fx23.iad> |
| In reply to | #27157 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-01 21:46 -0500 |
| Message-ID | <52c4d306$0$302$14726298@news.sunsite.dk> |
| In reply to | #27154 |
On 12/31/2013 11:52 AM, jebblue wrote: > On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote: > >> I find that I often stretch systems to there >> limits > 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. That sounds weird. 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 ORM should be a lot simpler. > Things like, slow performance, You should execute the same SQL with and without ORM - the only overhead is the extra processing in the ORM, which should be insignificant compared to actually getting the data from the database. > hassles when trying to relate > data between tables, That is a standard feature in all modern/common ORM's. > trying to sort out what I want the > SQL to do With an ORM you would typical not use SQL. > 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 is fewer changes than plain JDBC. Arne
[toc] | [prev] | [next] | [standalone]
| From | Gordon Levi <gordon@address.invalid> |
|---|---|
| Date | 2014-01-02 19:34 +1100 |
| Message-ID | <nm7ac9l3thd70u0b261ff90et4gjo538rp@4ax.com> |
| In reply to | #27159 |
Arne Vajhøj <arne@vajhoej.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.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-02 10:02 +0000 |
| Message-ID | <WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com> |
| In reply to | #27170 |
On 02/01/14 08:34, Gordon Levi wrote: > Arne Vajhøj <arne@vajhoej.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. 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". To add a single persisted field to an input form requires the modification of most if not all of the layers of an application. 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. 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 -- Lipska the Kat©: Troll hunter, sandbox destroyer, treacherous feline and farscape dreamer of Aeryn Sun GNU/Linux user #560883 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | "Qu0ll" <Qu0llSixFour@gmail.com> |
|---|---|
| Date | 2014-01-02 23:09 +1100 |
| Message-ID | <q5ednUW-SIOoyljPnZ2dnUVZ_qWdnZ2d@westnet.com.au> |
| In reply to | #27171 |
"lipska the kat" wrote in message news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... Reply at the end, sorry for the lack of indentation.., On 02/01/14 08:34, Gordon Levi wrote: > Arne Vajhøj <arne@vajhoej.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. 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". To add a single persisted field to an input form requires the modification of most if not all of the layers of an application. 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. 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 -------------------------- I find myself actually agreeing with you again. Adding even a single field to the underlying data structures is *not* straightforward at all in a typical Java application. I also tend to agree with your comment regarding ORMs v. standard SQL. -- And loving it, -Qu0ll (Rare, not extinct) _________________________________________________ Qu0llSixFour@gmail.com [Replace the "SixFour" with numbers to email me]
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-02 12:22 +0000 |
| Message-ID | <1YCdnSe_JYu9x1jPnZ2dnUVZ8rydnZ2d@bt.com> |
| In reply to | #27173 |
On 02/01/14 12:09, Qu0ll wrote: > "lipska the kat" wrote in message > news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... > > > Reply at the end, sorry for the lack of indentation.., > <snip> > 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". > > To add a single persisted field to an input form requires the > modification of most if not all of the layers of an application. > > 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. > > 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 > > -------------------------- > > I find myself actually agreeing with you again. Steady now > Adding even a single field to the underlying data structures is *not* > straightforward at all in a typical Java application. > > I also tend to agree with your comment regarding ORMs v. standard SQL. Twice? In one day? What were you drinking new years eve :-) Only kidding, nice to know it's not just me. > > -- > And loving it, > > -Qu0ll (Rare, not extinct) > _________________________________________________ > Qu0llSixFour@gmail.com > [Replace the "SixFour" with numbers to email me] -- Lipska the Kat©: Troll hunter, sandbox destroyer, treacherous feline and farscape dreamer of Aeryn Sun GNU/Linux user #560883 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | Gordon Levi <gordon@address.invalid> |
|---|---|
| Date | 2014-01-03 20:06 +1100 |
| Message-ID | <ilucc9lp5mghpjto77l4aot1cpqikoocm7@4ax.com> |
| In reply to | #27173 |
"Qu0ll" <Qu0llSixFour@gmail.com> wrote: >"lipska the kat" wrote in message >news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... > > >Reply at the end, sorry for the lack of indentation.., > > >On 02/01/14 08:34, Gordon Levi wrote: >> Arne Vajhøj <arne@vajhoej.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. > >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". > >To add a single persisted field to an input form requires the >modification of most if not all of the layers of an application. > >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. > >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 > >-------------------------- > >I find myself actually agreeing with you again. > >Adding even a single field to the underlying data structures is *not* >straightforward at all in a typical Java application. I'm sorry if you both have had a hard time adding a field to a database but it is not relevant to my post. I believe that adding a field to a database should require _no_ alterations to any program that accesses the database unless the program needs to process the field. The extra code that processing the field requires could take from one day to several man years. If you work for a large corporation you can change one day to one month but that is beside the point. > >I also tend to agree with your comment regarding ORMs v. standard SQL.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-03 09:17 +0000 |
| Message-ID | <kPWdnb_b0_6pHVvPnZ2dnUVZ7qqdnZ2d@bt.com> |
| In reply to | #27188 |
On 03/01/14 09:06, Gordon Levi wrote: > "Qu0ll" <Qu0llSixFour@gmail.com> wrote: > >> "lipska the kat" wrote in message >> news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... >> >> >> Reply at the end, sorry for the lack of indentation.., >> >> >> On 02/01/14 08:34, Gordon Levi wrote: >>> Arne Vajhøj <arne@vajhoej.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. >> >> 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". >> >> To add a single persisted field to an input form requires the >> modification of most if not all of the layers of an application. >> >> 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. >> >> 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 >> >> -------------------------- >> >> I find myself actually agreeing with you again. >> >> Adding even a single field to the underlying data structures is *not* >> straightforward at all in a typical Java application. > > I'm sorry if you both have had a hard time adding a field to a > database but it is not relevant to my post. I believe that adding a > field to a database should require _no_ alterations to any program > that accesses the database unless the program needs to process the > field. Ah, yes *majik* I'd forgotten about that, well done, where did you get your wand? can I get one? -- Lipska the Kat©: Troll hunter, sandbox destroyer, treacherous feline and farscape dreamer of Aeryn Sun GNU/Linux user #560883 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | Gordon Levi <gordon@address.invalid> |
|---|---|
| Date | 2014-01-04 00:41 +1100 |
| Message-ID | <65edc99f739r4dog17d1eo4tf693013dmd@4ax.com> |
| In reply to | #27190 |
lipska the kat <lipskathekat@example.com> wrote: >On 03/01/14 09:06, Gordon Levi wrote: >> "Qu0ll" <Qu0llSixFour@gmail.com> wrote: >> >>> "lipska the kat" wrote in message >>> news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... >>> >>> >>> Reply at the end, sorry for the lack of indentation.., >>> >>> >>> On 02/01/14 08:34, Gordon Levi wrote: >>>> Arne Vajhøj <arne@vajhoej.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. >>> >>> 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". >>> >>> To add a single persisted field to an input form requires the >>> modification of most if not all of the layers of an application. >>> >>> 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. >>> >>> 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 >>> >>> -------------------------- >>> >>> I find myself actually agreeing with you again. >>> >>> Adding even a single field to the underlying data structures is *not* >>> straightforward at all in a typical Java application. >> >> I'm sorry if you both have had a hard time adding a field to a >> database but it is not relevant to my post. I believe that adding a >> field to a database should require _no_ alterations to any program >> that accesses the database unless the program needs to process the >> field. > >Ah, yes *majik* I'd forgotten about that, well done, where did you get >your wand? can I get one? Edgar Codd gave you the wand forty years ago. Christopher Date explained how to use it and an unnamed hero at Sun Microsystems made sure it was available in Java with JDBC.
[toc] | [prev] | [next] | [standalone]
| From | leif.roar@invalid.com (Leif Roar Moldskred) |
|---|---|
| Date | 2014-01-03 06:41 -0600 |
| Message-ID | <F5GdnV1lUNN-MlvPnZ2dnUVZ8nSdnZ2d@giganews.com> |
| In reply to | #27188 |
Gordon Levi <gordon@address.invalid> wrote: > > I believe that adding a > field to a database should require _no_ alterations to any program > that accesses the database unless the program needs to process the > field. And it won't -- assuming there are no constraints placed on the new field, and none of your SQL calls depend on the particular ordering or cardinality of the columns in that particular table. Oh, and of course assuming that none of the triggers or stored procedures in the database depend on the particular ordering or cardinality of the columns either. Oh, _and_ assuming that the new field doesn't cause Oracle to choose a new, much slower evaluation pathway for any of your SQL calls just out of spite. -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2014-01-03 14:56 +0000 |
| Message-ID | <Rd-dnXBztdWUTVvPnZ2dnUVZ8hcAAAAA@bt.com> |
| In reply to | #27194 |
Leif Roar Moldskred wrote:
> Gordon Levi <gordon@address.invalid> wrote:
> >
> > I believe that adding a
> > field to a database should require _no_ alterations to any program
> > that accesses the database unless the program needs to process the
> > field.
>
> And it won't -- assuming [snipped].
And assuming that there is a sensible default value for the new column to take.
-- chris
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 12:12 -0400 |
| Message-ID | <tjBxu.258173$ad.164646@fx04.iad> |
| In reply to | #27194 |
On 01/03/2014 08:41 AM, Leif Roar Moldskred wrote: > Gordon Levi <gordon@address.invalid> wrote: >> >> I believe that adding a >> field to a database should require _no_ alterations to any program >> that accesses the database unless the program needs to process the >> field. > > And it won't -- assuming there are no constraints placed on the new > field, and none of your SQL calls depend on the particular ordering > or cardinality of the columns in that particular table. Oh, and of > course assuming that none of the triggers or stored procedures in > the database depend on the particular ordering or cardinality of > the columns either. > > Oh, _and_ assuming that the new field doesn't cause Oracle to > choose a new, much slower evaluation pathway for any of your > SQL calls just out of spite. > In the wider context of this thread, technical matters this specific make sense only to DBAs and a small percentage of developers. Most developers who resort to using SQL don't even understand this stuff. People created SQL, JDBC and ORMs so 99 percent of the developers could be insulated from this information. 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 | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-03 19:30 +0000 |
| Message-ID | <la7357$d2p$1@dont-email.me> |
| In reply to | #27207 |
On Fri, 03 Jan 2014 12:12:09 -0400, Arved Sandstrom wrote: > In the wider context of this thread, technical matters this specific > make sense only to DBAs and a small percentage of developers. Most > developers who resort to using SQL don't even understand this stuff. > That might matter to me inasmuch as I do understand the use of EXPLAIN and similar tools to understand why an SQL query is slower than expected and how use the tool's output to decide if a speed-up is worth it and, if so, how to modify the query and/or the schema. Are there similar ORM tools and if so, do they tend to be generic or ORM- implementation specific? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 16:04 -0400 |
| Message-ID | <tJExu.183218$cZ.27398@fx31.iad> |
| In reply to | #27210 |
On 01/03/2014 03:30 PM, Martin Gregorie wrote: > On Fri, 03 Jan 2014 12:12:09 -0400, Arved Sandstrom wrote: > >> In the wider context of this thread, technical matters this specific >> make sense only to DBAs and a small percentage of developers. Most >> developers who resort to using SQL don't even understand this stuff. >> > That might matter to me inasmuch as I do understand the use of EXPLAIN > and similar tools to understand why an SQL query is slower than expected > and how use the tool's output to decide if a speed-up is worth it and, if > so, how to modify the query and/or the schema. > > Are there similar ORM tools and if so, do they tend to be generic or ORM- > implementation specific? > Martin, the SQL generated by Java ORMs is not hidden. Suitable logging levels expose the generated SQL. If you distrust that logging there are always DB profilers. Many/most ORMs are open source: when in doubt, investigate the code...I've tweaked several Java ORMs after code inspection. In my opinion the first and usually the best "tool" is simply the native implementation spec. I do myself understand execution plans quite well, but not nearly as well as a good DBA. In most consulting engagements that involve RDBMSs, if performance issues get tricky I do not hesitate to talk to a resident DBA: that's another great "tool". 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 | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-03 22:30 +0000 |
| Message-ID | <la7dmo$f7o$1@dont-email.me> |
| In reply to | #27211 |
On Fri, 03 Jan 2014 16:04:40 -0400, Arved Sandstrom wrote: > Martin, the SQL generated by Java ORMs is not hidden. Suitable logging > levels expose the generated SQL. If you distrust that logging there are > always DB profilers. Many/most ORMs are open source: when in doubt, > investigate the code...I've tweaked several Java ORMs after code > inspection. > I'd assumed that the ORM would be generating SQL, so its good to know that what it generates can be inspected. Not that I'm casting nasturtiums at ORMS, but I've seen some truly dreadful automatically generated SQL in the past (Sybase PowerBuilder, I'm looking at you), so I tend to be suspicious of auto-generated SQL. However, I was wondering whether there any performance problems could come from the way an ORM uses its generated SQL and what tools might be available to analyse them. > In my opinion the first and usually the best "tool" is simply the native > implementation spec. > Fair comment. > I do myself understand execution plans quite well, but not nearly as > well as a good DBA. In most consulting engagements that involve RDBMSs, > if performance issues get tricky I do not hesitate to talk to a resident > DBA: that's another great "tool". > I've had a fairly varied range of experience ranging from application implementation and design over a range of databases (IDMSX as well as relational) and languages and have also been both sysadmin and DBA on several OSen and DBMS, eventually realising that I was getting typecast as a DBA/DB designer and general DB performance tuner. At that point I had to take positive action to get back into systems development, but have never entirely left that skill set behind. This is why I'm curious about this area. ...just so's you know. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-05 23:44 -0400 |
| Message-ID | <qEpyu.98732$wB.25015@fx28.iad> |
| In reply to | #27221 |
On 01/03/2014 06:30 PM, Martin Gregorie wrote: > On Fri, 03 Jan 2014 16:04:40 -0400, Arved Sandstrom wrote: > >> Martin, the SQL generated by Java ORMs is not hidden. Suitable logging >> levels expose the generated SQL. If you distrust that logging there are >> always DB profilers. Many/most ORMs are open source: when in doubt, >> investigate the code...I've tweaked several Java ORMs after code >> inspection. >> > I'd assumed that the ORM would be generating SQL, so its good to know > that what it generates can be inspected. Not that I'm casting nasturtiums > at ORMS, but I've seen some truly dreadful automatically generated SQL in > the past (Sybase PowerBuilder, I'm looking at you), so I tend to be > suspicious of auto-generated SQL. > > However, I was wondering whether there any performance problems could > come from the way an ORM uses its generated SQL and what tools might be > available to analyse them. [ SNIP ] Martin, I'd be generally inclined to tackle the possible performance problem by using ORM logging first, RDBMS tracing/profiling second to further narrow down issues, and only then backtracking to the ORM to code review (or worst case dive into open source ORM code and make changes). 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 | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 16:28 -0500 |
| Message-ID | <52c72b6b$0$298$14726298@news.sunsite.dk> |
| In reply to | #27210 |
On 1/3/2014 2:30 PM, Martin Gregorie wrote: > On Fri, 03 Jan 2014 12:12:09 -0400, Arved Sandstrom wrote: >> In the wider context of this thread, technical matters this specific >> make sense only to DBAs and a small percentage of developers. Most >> developers who resort to using SQL don't even understand this stuff. >> > That might matter to me inasmuch as I do understand the use of EXPLAIN > and similar tools to understand why an SQL query is slower than expected > and how use the tool's output to decide if a speed-up is worth it and, if > so, how to modify the query and/or the schema. > > Are there similar ORM tools and if so, do they tend to be generic or ORM- > implementation specific? Since most ORM's support multiple databases that may have different performance characteristics, then explaining ORM may be difficult. Most ORM's allows you to dump the actual executed SQL against a specific database and that SQL can be explained. So if you have a specific performance problem using a specific database, then you can investigate. But as a general rule of thumb, then I would say that the SQL becomes so complex that you need to explain different variants to find out what is performing best in a specific database, then you should start considering whether an ORM is the right tool for the job. Arne
[toc] | [prev] | [next] | [standalone]
Page 7 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