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 8 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:08 -0500 |
| Message-ID | <52c726e2$0$304$14726298@news.sunsite.dk> |
| In reply to | #27188 |
On 1/3/2014 4:06 AM, Gordon Levi wrote: > "Qu0ll" <Qu0llSixFour@gmail.com> wrote: >> "lipska the kat" wrote in message >> news:WJCdnYC44fWipFjPnZ2dnUVZ8sidnZ2d@bt.com... >> 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. We are discussing how to do it when the program does need to use the field. The fact that no changes are needed if the field is not used is correct but not very relevant as an argument for or against ORM. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 16:22 -0400 |
| Message-ID | <v_Exu.191837$O25.169675@fx21.iad> |
| In reply to | #27173 |
On 01/02/2014 08:09 AM, Qu0ll 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 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] Adding a field - either at the DB table level, or at a more abstract OO level - isn't trivial, but neither is it usually brutally difficult. Not from a developer standpoint. It's usually straightforward, just time consuming, as I mentioned in another post. Too many changes like this leads to "death by a thousand cuts". As I mentioned in that same post, the real issue with changes like this is that some end user, client, PM, architect or designer is vacillating or being incompetent or not resisting ill-advised requests. The problem is higher up the food chain. And even when programmers are asked to make a change like this, the bulk of expended effort is not at the data access layer level. You guys have yourselves intimated this, or flat out said it. So if most of the work is not at the DAL level, but happens in business logic or the presentation layer, *and* the choice and employment of JPA, native ORM, JDBC, SQL etc is confined to the DAL, why is it not fundamentally a problem with human beings? It's not the fault of an ORM. 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 | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 00:29 -0400 |
| Message-ID | <U0rxu.80422$VG.16324@fx12.iad> |
| In reply to | #27171 |
On 01/02/2014 06:02 AM, lipska the kat wrote: > 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". Most BA, end user, customer, and PM requests send shivers down developers' spines. :-) > To add a single persisted field to an input form requires the > modification of most if not all of the layers of an application. If it's actually a persisted field in an input form (various types of data input mechanisms related to or from HTML, MS, Oracle, Adobe, IBM, etc), I agree. That by definition affects _every_ layer. > Adding a single field to a product line for example would probably > require the modification of all the CRUD methods for that line, not to > mention the inclusion of the field in the search algorithms, modifying > the validation layer, incorporating the field in a logical place in the > HCI, modifying and refactoring the relevant code etc etc. Anything that > can reduce the amount of work required to implement such an apparently > trivial change has got to be a good idea. From the implementation standpoint a persisted field addition, deletion or modification, in a complete stack scenario, will consume at least a man-day, and possibly several. It really won't make much of a difference as to whether a Java ORM or JDBC is involved...not on average. The actual problem with changes of this sort is that someone a bit higher up than the grunt coder altered the requirements, or the design. Proponents of agile have bent over backwards to accommodate these ineffiencies: this is just letting non-technological people dictate implementation. > Having said that, I don't used ORMs myself, I mean I've tried, I've > really tried but I start reading the documentation and my eyes glaze > over and I discover that I need to learn 'another' (query) language and > I decide that it's just not worth the effort. Stick to SQL, accept the > overhead and I don't think you can go far wrong. > > Just my 2 euros worth > The JPA specs are some of the best specs I've seen. The associated specs for the actual implementations are also quite good. If your eyes are glazing over when you try to read these, I'm pretty sure you've got a hell of a time with almost every other spec out there. Feel free to stick to SQL and waste substantial time doing NIH. It could just be me, but I like it when I get a substantial assist creating objects out of relational data. You just now above said "accept the overhead": guess what, there's a lot of overhead. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-03 09:08 +0000 |
| Message-ID | <g-ydnYAByYyT41vPnZ2dnUVZ8smdnZ2d@bt.com> |
| In reply to | #27186 |
On 03/01/14 04:29, Arved Sandstrom wrote: > On 01/02/2014 06:02 AM, lipska the kat wrote: >> 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". > > Most BA, end user, customer, and PM requests send shivers down > developers' spines. :-) > >> To add a single persisted field to an input form requires the >> modification of most if not all of the layers of an application. > > If it's actually a persisted field in an input form (various types of > data input mechanisms related to or from HTML, MS, Oracle, Adobe, IBM, > etc), I agree. That by definition affects _every_ layer. > >> Adding a single field to a product line for example would probably >> require the modification of all the CRUD methods for that line, not to >> mention the inclusion of the field in the search algorithms, modifying >> the validation layer, incorporating the field in a logical place in the >> HCI, modifying and refactoring the relevant code etc etc. Anything that >> can reduce the amount of work required to implement such an apparently >> trivial change has got to be a good idea. > > From the implementation standpoint a persisted field addition, deletion > or modification, in a complete stack scenario, will consume at least a > man-day, and possibly several. It really won't make much of a difference > as to whether a Java ORM or JDBC is involved...not on average. > > The actual problem with changes of this sort is that someone a bit > higher up than the grunt coder altered the requirements, or the design. > Proponents of agile have bent over backwards to accommodate these > ineffiencies: this is just letting non-technological people dictate > implementation. > >> Having said that, I don't used ORMs myself, I mean I've tried, I've >> really tried but I start reading the documentation and my eyes glaze >> over and I discover that I need to learn 'another' (query) language and >> I decide that it's just not worth the effort. Stick to SQL, accept the >> overhead and I don't think you can go far wrong. >> >> Just my 2 euros worth >> > > The JPA specs are some of the best specs I've seen. The associated specs > for the actual implementations are also quite good. If your eyes are > glazing over when you try to read these, I'm pretty sure you've got a > hell of a time with almost every other spec out there. Now now, you're making assumptions again aren't you. They're glazing over through BOREDOM, any other assumption is erroneous. I'd rather spend the time improving my SQL skills. This whole business about saving time and 'making things easier' doesn't always chime. Work for company A they use ORM X, learn ORM X, still need SQL to do stuff the ORM can't manage. Work for company B they use ORM Y, learn ORM Y, still need SQL to do (different) stuff the ORM can't manage. See a common thread here. I'll stick to SQL thanks. > Feel free to stick to SQL and waste substantial time doing NIH. I'm not American > It could > just be me, but I like it when I get a substantial assist creating > objects out of relational data. You just now above said "accept the > overhead": guess what, there's a lot of overhead. I'll tell you what, I'll spend whatever time is required to learn one of these XML ... oops ORMs when one comes along that allows me to write classes that don't need primary keys. To me, 'mapping' an object to an RDBMS table (or multiple tables in some cases) means persisting my Object graph without any of the relational database stuff creeping in, and I include annotations, comments, pointed sticks or any other artifact that is only included to enable the ORM, and yes I know about the alternatives. I keep wondering if it's possible using reflection and introspection ... Hope this clears things up. -- 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 | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 10:18 -0400 |
| Message-ID | <LEzxu.105024$Qi4.31733@fx11.iad> |
| In reply to | #27189 |
On 01/03/2014 05:08 AM, lipska the kat wrote: > On 03/01/14 04:29, Arved Sandstrom wrote: >> On 01/02/2014 06:02 AM, lipska the kat wrote: >>> 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". >> >> Most BA, end user, customer, and PM requests send shivers down >> developers' spines. :-) >> >>> To add a single persisted field to an input form requires the >>> modification of most if not all of the layers of an application. >> >> If it's actually a persisted field in an input form (various types of >> data input mechanisms related to or from HTML, MS, Oracle, Adobe, IBM, >> etc), I agree. That by definition affects _every_ layer. >> >>> Adding a single field to a product line for example would probably >>> require the modification of all the CRUD methods for that line, not to >>> mention the inclusion of the field in the search algorithms, modifying >>> the validation layer, incorporating the field in a logical place in the >>> HCI, modifying and refactoring the relevant code etc etc. Anything that >>> can reduce the amount of work required to implement such an apparently >>> trivial change has got to be a good idea. >> >> From the implementation standpoint a persisted field addition, deletion >> or modification, in a complete stack scenario, will consume at least a >> man-day, and possibly several. It really won't make much of a difference >> as to whether a Java ORM or JDBC is involved...not on average. >> >> The actual problem with changes of this sort is that someone a bit >> higher up than the grunt coder altered the requirements, or the design. >> Proponents of agile have bent over backwards to accommodate these >> ineffiencies: this is just letting non-technological people dictate >> implementation. >> >>> Having said that, I don't used ORMs myself, I mean I've tried, I've >>> really tried but I start reading the documentation and my eyes glaze >>> over and I discover that I need to learn 'another' (query) language and >>> I decide that it's just not worth the effort. Stick to SQL, accept the >>> overhead and I don't think you can go far wrong. >>> >>> Just my 2 euros worth >>> >> >> The JPA specs are some of the best specs I've seen. The associated specs >> for the actual implementations are also quite good. If your eyes are >> glazing over when you try to read these, I'm pretty sure you've got a >> hell of a time with almost every other spec out there. > > Now now, you're making assumptions again aren't you. > They're glazing over through BOREDOM, any other assumption is erroneous. You're making assumptions yourself. I didn't imply that you were mentally retarded. I merely observed that if your eyes glaze over when reading JPA or Java ORM specs, your eyes must glaze over when reading most other specs. I don't exactly choose programming specs for Saturday afternoon reading either. I haven't run across any that keep me glued to the pages like a Jeffrey Archer or Ken Follett novel. But material on JDBC or SQL ain't any easier to read than JPA specs. > I'd rather spend the time improving my SQL skills. This whole business > about saving time and 'making things easier' doesn't always chime. Work > for company A they use ORM X, learn ORM X, still need SQL to do stuff > the ORM can't manage. Work for company B they use ORM Y, learn ORM Y, > still need SQL to do (different) stuff the ORM can't manage. See a > common thread here. > > I'll stick to SQL thanks. I see a common thread: meaning no offense, I think you are biased towards SQL to the extent that you are discounting more abstract data access technologies...not that SQL is actually that close to the metal either. If you're dealing with Java ORMs, incidentally, there probably is only X and Y: as in two major ORMs. It's not that onerous to learn two technologies, and since both support JPA, it's even less trouble. As to SQL being superior because you sometimes have to use it, that's like me claiming that C is superior and the preferred language because every once in a while I've had to do things like SWIG or Perl XS or JNI. >> Feel free to stick to SQL and waste substantial time doing NIH. > > I'm not American I am. I'm also Canadian and Estonian. :-) But you understood the term "NIH". I'd be interested to hear how a constant use of SQL saves time. That leads to usually re-inventing the wheel. Myself, I'd advocate using a carefully chosen subset of JPA about 80-90 percent of the time, and using SQL for the rest. I'd also advocate a fairly thorough knowledge of a chosen ORM: a lot of critics of ORMs have bitched about gotchas and inefficiencies and complexities, but yet you've also got all that with SQL. >> It could >> just be me, but I like it when I get a substantial assist creating >> objects out of relational data. You just now above said "accept the >> overhead": guess what, there's a lot of overhead. > > I'll tell you what, I'll spend whatever time is required to learn one of > these XML ... oops ORMs when one comes along that allows me to write > classes that don't need primary keys. I'll assume that you are not questioning the general usefulness of primary, composite or surrogate keys. :-) Having said that, are _you_ able to dispense with primary or foreign keys when writing SQL or JDBC? Probably not. So why do you expect that with an ORM? The level of abstraction is not that much greater. To me, 'mapping' an object to an > RDBMS table (or multiple tables in some cases) means persisting my > Object graph without any of the relational database stuff creeping in, Don't choose an ORM then. :-) The 'R' sorta means that "relational stuff" creeps in. Although if you can write SQL in a data access layer, and generate objects for use by the BL layer or higher, I'd be curious to find out how you can ignore "relational stuff". > and I include annotations, comments, pointed sticks or any other > artifact that is only included to enable the ORM, and yes I know about > the alternatives. What alternatives? XML? > I keep wondering if it's possible using reflection and introspection ... Feel free. If you're going to do that, may as well devise an efficient file structure for data storage, and write C or C++ for access. Oh, wait...Oracle and MS and a bunch of other companies already did that. > Hope this clears things up. > > It clears things up. We still disagree. :-) 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 | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-03 15:24 +0000 |
| Message-ID | <s-GdndvRrO-tS1vPnZ2dnUVZ8oGdnZ2d@bt.com> |
| In reply to | #27198 |
On 03/01/14 14:18, Arved Sandstrom wrote: > On 01/03/2014 05:08 AM, lipska the kat wrote: >> On 03/01/14 04:29, Arved Sandstrom wrote: >>> On 01/02/2014 06:02 AM, lipska the kat wrote: >>>> 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. <snip> >>>> >>>> Just my 2 euros worth >>>> >>> >>> The JPA specs are some of the best specs I've seen. The associated specs >>> for the actual implementations are also quite good. If your eyes are >>> glazing over when you try to read these, I'm pretty sure you've got a >>> hell of a time with almost every other spec out there. >> >> Now now, you're making assumptions again aren't you. >> They're glazing over through BOREDOM, any other assumption is erroneous. > > You're making assumptions yourself. I didn't imply that you were > mentally retarded. I merely observed that if your eyes glaze over when > reading JPA or Java ORM specs, your eyes must glaze over when reading > most other specs. Actually, RFC2616 and updates has been my preferred bedtime reading for the past few years, I still browse it from time to time. I also enjoy the HTML5 and CSS3 specs along with a regular perusal of the latest Java API docs, so no to general glazing overness but yes to glazing overness when it comes to third party frameworks ... I just can't get excited about them. I prefer to be in control quite frankly and not rely on what someone else thinks is the right way to do something. > I don't exactly choose programming specs for Saturday afternoon reading > either. I haven't run across any that keep me glued to the pages like a > Jeffrey Archer Now I know you're kidding, Jeffrey Archer!!! *Jeffrey Archer* jeez, the man's an imbicile. > or Ken Follett novel. But material on JDBC or SQL ain't > any easier to read than JPA specs. Yes but it's so much more *interesting* >> I'd rather spend the time improving my SQL skills. This whole business >> about saving time and 'making things easier' doesn't always chime. Work >> for company A they use ORM X, learn ORM X, still need SQL to do stuff >> the ORM can't manage. Work for company B they use ORM Y, learn ORM Y, >> still need SQL to do (different) stuff the ORM can't manage. See a >> common thread here. >> >> I'll stick to SQL thanks. > > I see a common thread: meaning no offense, I think you are biased > towards SQL to the extent that you are discounting more abstract data > access technologies...not that SQL is actually that close to the metal > either. Actually I just can't be arsed with frameworks, I try too get closer to the machine, not further away from it. > If you're dealing with Java ORMs, incidentally, there probably is only X > and Y: as in two major ORMs. It's not that onerous to learn two > technologies, and since both support JPA, it's even less trouble. > > As to SQL being superior because you sometimes have to use it, that's > like me claiming that C is superior and the preferred language. C is god, there is no competetion. I went with Java bacause that is where the money was when I graduated, I was cracking C when I was first year Uni, I broke their network simulators in about 5 minutes flat, I like C ... but I've done better out of Java. > because > every once in a while I've had to do things like SWIG or Perl XS or JNI. > >>> Feel free to stick to SQL and waste substantial time doing NIH. That's very kind of you, I will :-) >> >> I'm not American > > I am. I'm also Canadian and Estonian. :-) But you understood the term > "NIH". Not Invented Here has nothing to do with it. I'm Canadian born, Vancouver BC (and Scottish) > I'd be interested to hear how a constant use of SQL saves time. That > leads to usually re-inventing the wheel. Myself, I'd advocate using a > carefully chosen subset of JPA about 80-90 percent of the time, and > using SQL for the rest. I'd also advocate a fairly thorough knowledge of > a chosen ORM: a lot of critics of ORMs have bitched about gotchas and > inefficiencies and complexities, but yet you've also got all that with SQL. Yes, but it's just *one set of complexities* >>> It could >>> just be me, but I like it when I get a substantial assist creating >>> objects out of relational data. You just now above said "accept the >>> overhead": guess what, there's a lot of overhead. >> >> I'll tell you what, I'll spend whatever time is required to learn one of >> these XML ... oops ORMs when one comes along that allows me to write >> classes that don't need primary keys. > > I'll assume that you are not questioning the general usefulness of > primary, composite or surrogate keys. :-) RDBMS Keys of whatever type and complexity are irrelevant to an Object graph. RDBMS Keys are needed in my Object models if I want to load and store instances from and to an RDBMS, they don't belong there, they annoy me and they destroy the beautiful simplicity of explicit relationships implemented by aggregation and composition. If it was up to me I wouldn't have the bloody things anywhere near my code. > Having said that, are _you_ able to dispense with primary or foreign > keys when writing SQL or JDBC? Probably not. So why do you expect that > with an ORM? The level of abstraction is not that much greater. I'm quite happy with keys in a database, that's how RDBMS works, saying I don't like keys in an RDBMS is just silly. > To me, 'mapping' an object to an >> RDBMS table (or multiple tables in some cases) means persisting my >> Object graph without any of the relational database stuff creeping in, > > Don't choose an ORM then. :-) Ah, now you're getting it :-) > The 'R' sorta means that "relational > stuff" creeps in. Although if you can write SQL in a data access layer, > and generate objects for use by the BL layer or higher, I'd be curious > to find out how you can ignore "relational stuff". Quantum memory, qbits, existential memory architectures that don't rely on constant voltages to maintain them, anything but keys in my classes. There is no really efficient way right now but there will be. Optical cube memory that can store terrabytes of bits in an instantly retrievable form, Martian server farms that store data on the network, HUGE conventional memory pools, distributed computing, freshly baked pretzels from Lidl ... I have no idea but I wish it would hurry up. >> and I include annotations, comments, pointed sticks or any other >> artifact that is only included to enable the ORM, and yes I know about >> the alternatives. > > What alternatives? XML? Actually I like XML, I've started to store entire tranches of data in XML in a database, it makes adding fields to a particular data cluster so much easier. ... and I'm getting *really* good with DOM :-) >> I keep wondering if it's possible using reflection and introspection ... > > Feel free. If you're going to do that, may as well devise an efficient > file structure for data storage, and write C or C++ for access. Oh, > wait...Oracle and MS and a bunch of other companies already did that. > >> Hope this clears things up. >> >> > It clears things up. We still disagree. :-) And isn't that a fantastic freedom that we need to carefully defend. -- 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 | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 17:10 -0400 |
| Message-ID | <mHFxu.183219$cZ.29917@fx31.iad> |
| In reply to | #27201 |
On 01/03/2014 11:24 AM, lipska the kat wrote: > On 03/01/14 14:18, Arved Sandstrom wrote: >> On 01/03/2014 05:08 AM, lipska the kat wrote: >>> On 03/01/14 04:29, Arved Sandstrom wrote: >>>> On 01/02/2014 06:02 AM, lipska the kat wrote: >>>>> 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. > > <snip> > >>>>> >>>>> Just my 2 euros worth >>>>> >>>> >>>> The JPA specs are some of the best specs I've seen. The associated >>>> specs >>>> for the actual implementations are also quite good. If your eyes are >>>> glazing over when you try to read these, I'm pretty sure you've got a >>>> hell of a time with almost every other spec out there. >>> >>> Now now, you're making assumptions again aren't you. >>> They're glazing over through BOREDOM, any other assumption is erroneous. >> >> You're making assumptions yourself. I didn't imply that you were >> mentally retarded. I merely observed that if your eyes glaze over when >> reading JPA or Java ORM specs, your eyes must glaze over when reading >> most other specs. > > Actually, RFC2616 and updates has been my preferred bedtime reading for > the past few years, I still browse it from time to time. I also enjoy > the HTML5 and CSS3 specs along with a regular perusal of the latest Java > API docs, so no to general glazing overness but yes to glazing overness > when it comes to third party frameworks ... I just can't get excited > about them. I prefer to be in control quite frankly and not rely on what > someone else thinks is the right way to do something. Therein lies our philosophical difference. In software development it is not possible to be in control. You may accomplish various semblances of "being in control", but nothing you do doesn't eventually rely on the efforts of dozens or hundreds of people. There isn't any major difference between the abstraction provided by a RDBMS DDL/DML or the abstraction provided by JDBC or an ORM. In none of those cases are *you* in control. If you really want control, revert to assembler or machine code, and create your data storage yourself. Even better, let's shoot for microcode. >> I don't exactly choose programming specs for Saturday afternoon reading >> either. I haven't run across any that keep me glued to the pages like a >> Jeffrey Archer > > Now I know you're kidding, Jeffrey Archer!!! *Jeffrey Archer* jeez, the > man's an imbicile. I'm not a personal friend of his, I've never met him. Given his career he's probably not an imbecile, though. Maybe not just your favourite author. Whatever people created Coronation Street are surely not imbeciles either, but I can't myself stand the show. >> or Ken Follett novel. But material on JDBC or SQL ain't >> any easier to read than JPA specs. > > Yes but it's so much more *interesting* > >>> I'd rather spend the time improving my SQL skills. This whole business >>> about saving time and 'making things easier' doesn't always chime. Work >>> for company A they use ORM X, learn ORM X, still need SQL to do stuff >>> the ORM can't manage. Work for company B they use ORM Y, learn ORM Y, >>> still need SQL to do (different) stuff the ORM can't manage. See a >>> common thread here. >>> >>> I'll stick to SQL thanks. >> >> I see a common thread: meaning no offense, I think you are biased >> towards SQL to the extent that you are discounting more abstract data >> access technologies...not that SQL is actually that close to the metal >> either. > > Actually I just can't be arsed with frameworks, I try too get closer to > the machine, not further away from it. Time and a place. Most every framework was created for a decent reason. The implementations may be imperfect, but that's no reason to abandon them. >> If you're dealing with Java ORMs, incidentally, there probably is only X >> and Y: as in two major ORMs. It's not that onerous to learn two >> technologies, and since both support JPA, it's even less trouble. >> >> As to SQL being superior because you sometimes have to use it, that's >> like me claiming that C is superior and the preferred language. > > C is god, there is no competetion. I went with Java bacause that is > where the money was when I graduated, I was cracking C when I was first > year Uni, I broke their network simulators in about 5 minutes flat, I > like C ... but I've done better out of Java. C is not god, languages like J and F# and Prolog are. I wouldn't let most coders approach C, although I myself really like C. I wouldn't let most coders tackle C++ either, not even the latest version. >> because >> every once in a while I've had to do things like SWIG or Perl XS or JNI. >> >>>> Feel free to stick to SQL and waste substantial time doing NIH. > > That's very kind of you, I will :-) > You're welcome. :-) >>> >>> I'm not American >> >> I am. I'm also Canadian and Estonian. :-) But you understood the term >> "NIH". > > Not Invented Here has nothing to do with it. I'm Canadian born, > Vancouver BC (and Scottish) > >> I'd be interested to hear how a constant use of SQL saves time. That >> leads to usually re-inventing the wheel. Myself, I'd advocate using a >> carefully chosen subset of JPA about 80-90 percent of the time, and >> using SQL for the rest. I'd also advocate a fairly thorough knowledge of >> a chosen ORM: a lot of critics of ORMs have bitched about gotchas and >> inefficiencies and complexities, but yet you've also got all that with >> SQL. > > Yes, but it's just *one set of complexities* I get that you're making that point. It's not entirely true, there are vendor variants of SQL. >>>> It could >>>> just be me, but I like it when I get a substantial assist creating >>>> objects out of relational data. You just now above said "accept the >>>> overhead": guess what, there's a lot of overhead. >>> >>> I'll tell you what, I'll spend whatever time is required to learn one of >>> these XML ... oops ORMs when one comes along that allows me to write >>> classes that don't need primary keys. >> >> I'll assume that you are not questioning the general usefulness of >> primary, composite or surrogate keys. :-) > > RDBMS Keys of whatever type and complexity are irrelevant to an Object > graph. RDBMS Keys are needed in my Object models if I want to load and > store instances from and to an RDBMS, they don't belong there, they > annoy me and they destroy the beautiful simplicity of explicit > relationships implemented by aggregation and composition. If it was up > to me I wouldn't have the bloody things anywhere near my code. Please tell me how you will _identify_ persisted objects? >> Having said that, are _you_ able to dispense with primary or foreign >> keys when writing SQL or JDBC? Probably not. So why do you expect that >> with an ORM? The level of abstraction is not that much greater. > [ SNIP ] >>> and I include annotations, comments, pointed sticks or any other >>> artifact that is only included to enable the ORM, and yes I know about >>> the alternatives. >> >> What alternatives? XML? > > Actually I like XML, I've started to store entire tranches of data in > XML in a database, it makes adding fields to a particular data cluster > so much easier. ... and I'm getting *really* good with DOM :-) Makes sense that you like DOM. It's a low-level interface, quite painful to use, and there are many better alternatives. :-) >>> I keep wondering if it's possible using reflection and introspection ... >> >> Feel free. If you're going to do that, may as well devise an efficient >> file structure for data storage, and write C or C++ for access. Oh, >> wait...Oracle and MS and a bunch of other companies already did that. >> >>> Hope this clears things up. >>> >>> >> It clears things up. We still disagree. :-) > > And isn't that a fantastic freedom that we need to carefully defend. > It is. 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 | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-04 10:02 +0000 |
| Message-ID | <7LednV8eOcPXQVrPnZ2dnUVZ8gGdnZ2d@bt.com> |
| In reply to | #27216 |
On 03/01/14 21:10, Arved Sandstrom wrote: > On 01/03/2014 11:24 AM, lipska the kat wrote: >> On 03/01/14 14:18, Arved Sandstrom wrote: >>> On 01/03/2014 05:08 AM, lipska the kat wrote: >>>> On 03/01/14 04:29, Arved Sandstrom wrote: >>>>> On 01/02/2014 06:02 AM, lipska the kat wrote: >>>>>> 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. <snip> >> Yes, but it's just *one set of complexities* > > I get that you're making that point. It's not entirely true, there are > vendor variants of SQL. Well that's an(other) interesting point. How many times in your career have you actually changed databases mid-stream? I'm not talking about prototyping, where you may use a simple lightweight database almost as a stub for prototyping purposes. I'm talking about the situation where you have a working application that's in the wild and making money, suddenly it is decided to change the database, say move from Oracle to a Microsoft product. The investment in the existing technology will be immense, switching vendors will require a huge additional investment in training, licensing blah blah blah ... yet this seems to be an oft quoted reason for using ORMs ... I have never experienced this myself. How often does it really happen? >>>>> It could >>>>> just be me, but I like it when I get a substantial assist creating >>>>> objects out of relational data. You just now above said "accept the >>>>> overhead": guess what, there's a lot of overhead. >>>> >>>> I'll tell you what, I'll spend whatever time is required to learn >>>> one of >>>> these XML ... oops ORMs when one comes along that allows me to write >>>> classes that don't need primary keys. >>> >>> I'll assume that you are not questioning the general usefulness of >>> primary, composite or surrogate keys. :-) >> >> RDBMS Keys of whatever type and complexity are irrelevant to an Object >> graph. RDBMS Keys are needed in my Object models if I want to load and >> store instances from and to an RDBMS, they don't belong there, they >> annoy me and they destroy the beautiful simplicity of explicit >> relationships implemented by aggregation and composition. If it was up >> to me I wouldn't have the bloody things anywhere near my code. > > Please tell me how you will _identify_ persisted objects? It will require a paradigm shift: (Thomas Kuhn: The Structure of Scientific Revolutions) The idea that objects need to be 'identified' is a direct consequence of the fact that the method of identifying the data needed to populate a 'persistent object' where that data is stored in an RDBMS is the 'key' and this is the point I'm trying to make. The RDBMS persistence model is so entrenched in our thoughts and minds that it can do nothing *but* influence our designs ... I could go on at length about this but I expect your eyes will start to glaze over :-) <snip> >> Actually I like XML, I've started to store entire tranches of data in >> XML in a database, it makes adding fields to a particular data cluster >> so much easier. ... and I'm getting *really* good with DOM :-) > > Makes sense that you like DOM. It's a low-level interface, quite painful > to use, and there are many better alternatives. :-) Heh heh, now you're getting it :-) -- 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 | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-04 16:02 +0000 |
| Message-ID | <la9bar$sj4$1@dont-email.me> |
| In reply to | #27228 |
On Sat, 04 Jan 2014 10:02:43 +0000, lipska the kat wrote: > How many times in your career have you actually changed databases > mid-stream? I'm not talking about prototyping, where you may use a > simple lightweight database almost as a stub for prototyping purposes. > Never - and that includes prototyping. IME a reason for prototyping has been to check that the projected data model can give the required performance on the selected database, which requires the prototype to use the target DBMS. I think a more likely case is when you're building a product that is required to run on a range of databases. > The idea that objects need to be 'identified' is a direct consequence of > the fact that the method of identifying the data needed to populate a > 'persistent object' where that data is stored in an RDBMS is the 'key' > and this is the point I'm trying to make. > Many real-world objects do have a natural identifier though and, as its something that people use to say which instance they are referring to, any computer system that deals with them muse use it as an identifier. Almost any product that complex or expensive enough to carry a guarantee will have a serial number. Many other items, e.g. musical compositions, can have a very complex identifier. For instance, a music librarian will tell you than that many classical compositions don't have a 'name' and can only be unambiguously identified by some combination of up attributes. The International Federation of Library Associations and Institutions (IFLA) defined a set of 14 attributes at least 35 years ago. Note that none of these are alternate identifiers: all 14 attributes are needed to create one unique identifier. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-04 17:27 +0000 |
| Message-ID | <2NSdnfhiEq0J2VXPnZ2dnUVZ7q6dnZ2d@bt.com> |
| In reply to | #27230 |
On 04/01/14 16:02, Martin Gregorie wrote: > On Sat, 04 Jan 2014 10:02:43 +0000, lipska the kat wrote: > >> How many times in your career have you actually changed databases >> mid-stream? I'm not talking about prototyping, where you may use a >> simple lightweight database almost as a stub for prototyping purposes. >> > Never - and that includes prototyping. IME a reason for prototyping has > been to check that the projected data model can give the required > performance on the selected database, which requires the prototype to use > the target DBMS. I've used MySQL in the past to throw together a prototype/proof of concept. I can download, install, configure and populate a simple database, knock up a quick Servlet/HTML interface and have something basic working in a few hours on my laptop that I can carry around with me, call it a throwaway prototype if you like. I had a look at the Oracle download, 2.5GB, MySQL is 290MB, that's lightweight :-) > I think a more likely case is when you're building a product that is > required to run on a range of databases. > >> The idea that objects need to be 'identified' is a direct consequence of >> the fact that the method of identifying the data needed to populate a >> 'persistent object' where that data is stored in an RDBMS is the 'key' >> and this is the point I'm trying to make. >> > Many real-world objects do have a natural identifier though and, as its > something that people use to say which instance they are referring to, > any computer system that deals with them muse use it as an identifier. Agreed, but this is different from the inclusion of a field (whatever that may be) who's only reason for being there is to provide a way to relate records in a relational database. Our friends in the north apparently don't see this as in any way intruding on the Object model, I do, in fact I've even found myself using the RDBMS 'key' lurking in a class as a key into a Map ... how crappy is that :-( > Almost any product that complex or expensive enough to carry a guarantee > will have a serial number. Many other items, e.g. musical compositions, > can have a very complex identifier. For instance, a music librarian will > tell you than that many classical compositions don't have a 'name' and > can only be unambiguously identified by some combination of up > attributes. The International Federation of Library Associations and > Institutions (IFLA) defined a set of 14 attributes at least 35 years ago. > Note that none of these are alternate identifiers: all 14 attributes are > needed to create one unique identifier. I have no problem with identifiers, every invoice I send out has an invoice number, it's an attribute of the invoice, it has nothing to do with databases. I don't have a problem with that. I also agree with the combination of attributes to provide an 'identifier' where required, in fact that is the ideal solution. I'm not being dogmatic here, it genuinely annoys the s*** out of me to pollute my nice clean Object model with fields who's reason for inclusion has nothing to do with the model. Maybe I need to get a life. -- 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 | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-04 12:46 -0500 |
| Message-ID | <52c8490c$0$305$14726298@news.sunsite.dk> |
| In reply to | #27231 |
On 1/4/2014 12:27 PM, lipska the kat wrote: > On 04/01/14 16:02, Martin Gregorie wrote: >> On Sat, 04 Jan 2014 10:02:43 +0000, lipska the kat wrote: >> >>> How many times in your career have you actually changed databases >>> mid-stream? I'm not talking about prototyping, where you may use a >>> simple lightweight database almost as a stub for prototyping purposes. >>> >> Never - and that includes prototyping. IME a reason for prototyping has >> been to check that the projected data model can give the required >> performance on the selected database, which requires the prototype to use >> the target DBMS. > > I've used MySQL in the past to throw together a prototype/proof of > concept. I can download, install, configure and populate a simple > database, knock up a quick Servlet/HTML interface and have something > basic working in a few hours on my laptop that I can carry around with > me, call it a throwaway prototype if you like. I had a look at the > Oracle download, 2.5GB, MySQL is 290MB, that's lightweight :-) You can get some big Oracle installers. But for this purpose Oracle XE seems sufficient. And that is a lot less (only 327 MB for 11.2 for Win32). Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-04 19:51 +0000 |
| Message-ID | <la9oou$erq$1@dont-email.me> |
| In reply to | #27231 |
On Sat, 04 Jan 2014 17:27:45 +0000, lipska the kat wrote: > I've used MySQL in the past to throw together a prototype/proof of > concept. > Interesting: that is one I'd specifically avoid because it, along with Oracle, has/had some of the most nonstandard SQL syntax of any RDBMS. If I was doing it on a Windows box I'd consider using Watcom DB (SQL Anywhere) but otherwise I'd use either Postgres, which I like a lot, or Derby. > Agreed, but this is different from the inclusion of a field (whatever > that may be) who's only reason for being there is to provide a way to > relate records in a relational database. > OK, that sounds more like what I know as an SDBK (soft database key): an integer containing a unique value and used as a prime key that has no domain-specific meaning. Generally I agree with you and avoid their use. However, I will use them in about three specific circumstances: a)where the natural identifier is complex, such as in the aforementioned musical work where using the complex key would make SQL queries almost unreadable b)where the natural identifier is very long and can appear in several rows, e.g. an e-mail subject line or address. In this case I'd create an operational master containing two fields: the sdbk as prime key and the subject as a unique, indexed alternate key. The message table which, in straight normalisation, would normally hold the subject, would instead carry the operational master's PK. The prime reason for introducing such an operational master is data volume reduction. c)I'd do the same as in (b) to e-mail addresses for exactly the same reasons but would, in addition implement a M:M link to the message body, making the address use (To, From, CC) an attribute of the entity that implemented the M:M relationship, so that one join on the three tables can retrieve all the messages sent to and received from that address. > apparently don't see this as in any way intruding on the Object model, I > do, in fact I've even found myself using the RDBMS 'key' lurking in a > class as a key into a Map ... how crappy is that :-( > Exactly so. The sdbk in (a) would almost certainly need to be an attribute of the equivalent class. In case (b) the class would probably just carry the alternate key. The M:M entity in (c) would be quite unlikely to form a separate class: it and the OM would probably become array elements in a Message class. > I'm not being dogmatic here, it genuinely annoys the s*** out of me to > pollute my nice clean Object model with fields who's reason for > inclusion has nothing to do with the model. Maybe I need to get a life. > Agreed, except as I said above, where the set of fields forming the key is so long that the SQL becomes unreadable. FWIW, the musical works key is an actual example from a fully normalised database, though it was implemented using IDMS rather than an RDBMS, and we cheated a bit. We realised that most of the fields were empty in every actual work and so we could generate a CSV-type field by concatenating the field contents with '@' separators after conversion to upper case and use the resulting 60 character string as the PK. We also kept the original field contents as data so it could be displayed as input. Key generation from the field list was a cheap operation even in COBOL and searching on the resulting key was fast within an IDMS ordered indexed set. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-04 19:24 -0500 |
| Message-ID | <52c8a631$0$297$14726298@news.sunsite.dk> |
| In reply to | #27236 |
On 1/4/2014 2:51 PM, Martin Gregorie wrote: > On Sat, 04 Jan 2014 17:27:45 +0000, lipska the kat wrote: >> I've used MySQL in the past to throw together a prototype/proof of >> concept. >> > Interesting: that is one I'd specifically avoid because it, along with > Oracle, has/had some of the most nonstandard SQL syntax of any RDBMS. If you are good with plain SQL-92 then any recent MySQL using default engine type should be OK. Some stuff from newer SQL versions like CTE, XML data type etc. are missing. You should not change the engine type from default (InnoDB) to MyISAM as that would break a lot of standard features. If you insist on using very funky names then start MySQL with --ansi to use standard quoted identifiers. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-04 14:08 -0500 |
| Message-ID | <52c85c18$0$299$14726298@news.sunsite.dk> |
| In reply to | #27228 |
On 1/4/2014 5:02 AM, lipska the kat wrote: > On 03/01/14 21:10, Arved Sandstrom wrote: >> On 01/03/2014 11:24 AM, lipska the kat wrote: >>> Yes, but it's just *one set of complexities* >> >> I get that you're making that point. It's not entirely true, there are >> vendor variants of SQL. > > Well that's an(other) interesting point. > How many times in your career have you actually changed databases > mid-stream? I'm not talking about prototyping, where you may use a > simple lightweight database almost as a stub for prototyping purposes. > I'm talking about the situation where you have a working application > that's in the wild and making money, suddenly it is decided to change > the database, say move from Oracle to a Microsoft product. The > investment in the existing technology will be immense, switching vendors > will require a huge additional investment in training, licensing blah > blah blah ... yet this seems to be an oft quoted reason for using ORMs > ... I have never experienced this myself. How often does it really happen? It happens occasionally. A company changes strategy. The company is acquired by another company or part of the company is spun off, which results in a new set of strategies. It is not that frequently though. But it is not so important for Arved's point, because there are other cases where developers need to cope with different SQL dialects: * the company uses more than one database (external customers using different databases, different internal departments using different databases) requiring developers to use different databases for different products/projects * developers changing job where the new company use a different database than the old company. For consultants/freelancers that happens very frequently. The majority of Java developers would use several different databases during a 10 year period. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 16:39 -0500 |
| Message-ID | <52c72e22$0$298$14726298@news.sunsite.dk> |
| In reply to | #27201 |
On 1/3/2014 10:24 AM, lipska the kat wrote: > On 03/01/14 14:18, Arved Sandstrom wrote: >> On 01/03/2014 05:08 AM, lipska the kat wrote: >>> On 03/01/14 04:29, Arved Sandstrom wrote: >>>> The JPA specs are some of the best specs I've seen. The associated >>>> specs >>>> for the actual implementations are also quite good. If your eyes are >>>> glazing over when you try to read these, I'm pretty sure you've got a >>>> hell of a time with almost every other spec out there. >>> >>> Now now, you're making assumptions again aren't you. >>> They're glazing over through BOREDOM, any other assumption is erroneous. >> >> You're making assumptions yourself. I didn't imply that you were >> mentally retarded. I merely observed that if your eyes glaze over when >> reading JPA or Java ORM specs, your eyes must glaze over when reading >> most other specs. > > Actually, RFC2616 and updates has been my preferred bedtime reading for > the past few years, I still browse it from time to time. I also enjoy > the HTML5 and CSS3 specs along with a regular perusal of the latest Java > API docs, so no to general glazing overness but yes to glazing overness > when it comes to third party frameworks ... I just can't get excited > about them. Then read Java EE API docs. Like JPA Criteria API. :-) >>> I'd rather spend the time improving my SQL skills. This whole business >>> about saving time and 'making things easier' doesn't always chime. Work >>> for company A they use ORM X, learn ORM X, still need SQL to do stuff >>> the ORM can't manage. Work for company B they use ORM Y, learn ORM Y, >>> still need SQL to do (different) stuff the ORM can't manage. See a >>> common thread here. >>> >>> I'll stick to SQL thanks. >> >> I see a common thread: meaning no offense, I think you are biased >> towards SQL to the extent that you are discounting more abstract data >> access technologies...not that SQL is actually that close to the metal >> either. > > Actually I just can't be arsed with frameworks, I try too get closer to > the machine, not further away from it. It has been known for more than 25 years that getting closer to the machine is not cost efficient given the way cost of hardware and cost of people evolve. >>>> It could >>>> just be me, but I like it when I get a substantial assist creating >>>> objects out of relational data. You just now above said "accept the >>>> overhead": guess what, there's a lot of overhead. >>> >>> I'll tell you what, I'll spend whatever time is required to learn one of >>> these XML ... oops ORMs when one comes along that allows me to write >>> classes that don't need primary keys. >> >> I'll assume that you are not questioning the general usefulness of >> primary, composite or surrogate keys. :-) > > RDBMS Keys of whatever type and complexity are irrelevant to an Object > graph. RDBMS Keys are needed in my Object models if I want to load and > store instances from and to an RDBMS, they don't belong there, they > annoy me and they destroy the beautiful simplicity of explicit > relationships implemented by aggregation and composition. If it was up > to me I wouldn't have the bloody things anywhere near my code. Well - you need the keys no matter whether you use ORM or plain JDBC. And besides the concept of object id is not only for persistence - you will need it for simple stuff like collections as well. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-02 20:43 -0500 |
| Message-ID | <52c615a8$0$302$14726298@news.sunsite.dk> |
| In reply to | #27170 |
On 1/2/2014 3:34 AM, 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. The context is that the class is persisted in a relational database. If you are not using an ORM you need to write code to do the database interface. Arne
[toc] | [prev] | [next] | [standalone]
| From | Gordon Levi <gordon@address.invalid> |
|---|---|
| Date | 2014-01-03 20:19 +1100 |
| Message-ID | <1evcc9hl6mk3gh5slh1r2ovjfmhutsl63e@4ax.com> |
| In reply to | #27181 |
Arne Vajhøj <arne@vajhoej.dk> wrote: >On 1/2/2014 3:34 AM, 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. > >The context is that the class is persisted in a relational >database. Thank you, it seems my fears are well founded. Does that mean that real Java programmers go to the trouble of breaking the relational model in order to maintain the object model? > >If you are not using an ORM you need to write code to do the >database interface. > >Arne >
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-03 09:23 +0000 |
| Message-ID | <kPWdnb7b0_4dHFvPnZ2dnUVZ7qqdnZ2d@bt.com> |
| In reply to | #27191 |
On 03/01/14 09:19, Gordon Levi wrote: > Arne Vajhøj <arne@vajhoej.dk> wrote: > >> On 1/2/2014 3:34 AM, 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. >> >> The context is that the class is persisted in a relational >> database. > > Thank you, it seems my fears are well founded. Does that mean that > real Java programmers go to the trouble of breaking the relational > model in order to maintain the object model? No, it usually means that the Object model is broken in order to maintain the relational model. -- 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 | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 11:34 -0400 |
| Message-ID | <oMAxu.204089$kN2.158802@fx19.iad> |
| In reply to | #27192 |
On 01/03/2014 05:23 AM, lipska the kat wrote: > On 03/01/14 09:19, Gordon Levi wrote: >> Arne Vajhøj <arne@vajhoej.dk> wrote: >> >>> On 1/2/2014 3:34 AM, 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. >>> >>> The context is that the class is persisted in a relational >>> database. >> >> Thank you, it seems my fears are well founded. Does that mean that >> real Java programmers go to the trouble of breaking the relational >> model in order to maintain the object model? > > No, it usually means that the Object model is broken in order to > maintain the relational model. > Programming, like any other discipline, is replete with people who create or seize on trendy theories or ideas, or start thinking that they understand really complex concepts when they have got 2 years of experience, or start tossing around high-faluting terminology. Not saying you are one. Having said that, some folks invented dubious concepts like object-relational impedance mismatch, likely because some of them knew a bit about EE. This unfortunate terminology has led to legions of people expounding on this "mismatch". For years you've had a whack of folks bending over backwards to academically opine on how bad this "mismatch" is. I may sound a bit like the kid who claimed that the emperor had no clothes, but let's be real: the object model is *not* broken when you deal with relational. Last I checked, any time I've used SQL via JDBC, or used JPA, I get pretty decent objects...and the object model is not broken at all. 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 | lipska the kat <lipskathekat@example.com> |
|---|---|
| Date | 2014-01-03 15:58 +0000 |
| Message-ID | <ZrudnVidLaaxQ1vPnZ2dnUVZ8tGdnZ2d@bt.com> |
| In reply to | #27202 |
On 03/01/14 15:34, Arved Sandstrom wrote: > On 01/03/2014 05:23 AM, lipska the kat wrote: >> On 03/01/14 09:19, Gordon Levi wrote: >>> Arne Vajhøj <arne@vajhoej.dk> wrote: >>> >>>> On 1/2/2014 3:34 AM, 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. >>>> >>>> The context is that the class is persisted in a relational >>>> database. >>> >>> Thank you, it seems my fears are well founded. Does that mean that >>> real Java programmers go to the trouble of breaking the relational >>> model in order to maintain the object model? >> >> No, it usually means that the Object model is broken in order to >> maintain the relational model. >> > Programming, like any other discipline, is replete with people who > create or seize on trendy theories or ideas, or start thinking that they > understand really complex concepts when they have got 2 years of > experience, or start tossing around high-faluting terminology. I have 18+ years and counting. Not as much as you no doubt but enough to have formulated my own opinions thank you very much. What other people do to impress their peers is of no concern to me. We used to play a game, when we had a 'consultant' come to visit, it was called bullshit bingo, the bigger the bullshitter the sooner someone would call 'bingo' the real boffins didn't have a single mark on their card. Go figure. > Not saying you are one. Hmmm. > Having said that, some folks invented dubious concepts like > object-relational impedance mismatch, likely because some of them knew a > bit about EE. This unfortunate terminology has led to legions of people > expounding on this "mismatch". For years you've had a whack of folks > bending over backwards to academically opine on how bad this "mismatch" is. Well academics need something to be 'all academic about' don't they, they would be out of a job otherwise wouldn't they. One of my professors called it 'mental masturbation'. Academia and real life rarely bother each other, just look at some of the nonsense posted in c.l.j.p. > I may sound a bit like the kid who claimed that the emperor had no > clothes, but let's be real: the object model is *not* broken when you > deal with relational. Bollocks, and I mean that most sincerely, If you *really* think about it and you're *really* honest with yourself can you think of one single time when you designed a system that you *knew beforehand would persist it's data in an RDBMS* where this knowledge didn't in some way, however sub-consciously impact the decisions you made when you were designing that system? > Last I checked, any time I've used SQL via JDBC, > or used JPA, I get pretty decent objects...and the object model is not > broken at all. What's a 'pretty decent object' ferchrissakes an Object is just a concrete realization of a class abstraction, either it's cohesive to that abstraction or it isn't ... pretty decent doesn't cut it. -- 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]
Page 8 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