ORM or JDBC?

[Arne Vajhøj]

Right. IOW - you _always_ have an object model when programming in Java
(since it is OO language). So take an example:

Let's say the purpose of an app is to allow the user to manipulate data in a
general ledger database (managed by a RDBMS).
My object model is GWT widget library (a set of classes implementing user
interface).
Do you know of any ORM tool that will allow me to "map" one to another?

No.

The use of ORM somewhat assume a separation between presentation
and data access layers.

The 1960's style of having everything in one big intertangled mess
does not fit well with ORM.

Or maybe you are saying I should design and develop _another_ class library
(an object model) and then design and develop _two_ mapping libraries (one
of them possibly based on some ORM tool) to achieve the goal?

Two independent problems:
database -> in memory model
in memory model -> display
should have two independent pieces of code.

Arne

 

[Arne Vajhøj]

Exactly my point - if that is the case then maintainig those classes and ORM
mapping code just adds cost without giving any benefits.
Been there done that, no thanks.

????

You seem to forget that you save to write your own data access layer.

That is a huge benefit.

Maybe. But what is a benefit of using ORM and data classes instead of
ResultSet and databound GUI controls?

The code in the ORM is maintained by somebody else.

The code you write to get data out of the ResultSet is something
you have to maintain.

I would say that's a myth. There is no way one can create a system that is
using RDBMS without knowledge about relational databases.

It is not a myth.

It is a fact that is observed every day in real life.

Arne

 

[Arne Vajhøj]

Is JDBC worth using?

In practice any database access you do on Java will use JDBC.

The only question is whether you see the JDBC or it is hidden
in some higher level library.

In most cases a higher level librray is better to use, but in
some cases getting down to JDBC is necessary.

I thought it was just a Java layer on top of ODBC.

No.

JDBC is an abstract abstract API.

There exist a so called JDBC-ODBC bridge that puts
a JDBC API on top of ODBC.

But that is just one out of many JDBC drivers.

And one that is rarely used outside of hello world
level.

Which nobody in their right mind uses.

ODBC is actually a fine C API.

SUN's JDBC-ODBC bridge sucks.

Arne

 

[Michal Kleczek]

No.

The use of ORM somewhat assume a separation between presentation
and data access layers.

They already _are_ separated. JDBC classes are designed to access data.
Swing (or any other widget library) classes are for presentation. They don't
have _anything_ in common.
To move data from one set of objects to another you can use ORM tool - the
problem is that ORM tools I know are not really helpful in this task.

The 1960's style of having everything in one big intertangled mess
does not fit well with ORM.


Two independent problems:
database -> in memory model
in memory model -> display
should have two independent pieces of code.

You seem to forget that "in memory model" of data stored in a database is
already implemented - it is abstracted as ResultSet/PreparedStatement.
Please - tell me what is the value of having _another_ "in memory
representation" just to move the data from ResultSets to GUI objects.

 

[Michal Kleczek]

No, but it is an antipattern to couple graphical widgets directly to the
data

Of course - and they are not coupled - GWT widget library has nothing to do
with JDBC and vice versa.

in the fashion you describe. Plus there is no framework such as you ask.

Widgets display values of objects,

Don't know what a "value of an object" is.
Widgets display state represented by values of _their_ properties.

not data tables.
True.

Any framework that
lets
the widgets use your data has to translate the data into an object.

The data is already translated to an object (instance of a class
implementing java.sql.ResultSet) by a JDBC driver.

That's what an ORM does

What ORM does (or shoud do) is it translates one representation of data (a
ResultSet) into another (user defined).
The problem is that existing ORMs fail to do it for arbitrary chosen class
models. Instead they force a programmer to define _another_ class model that
is suited for this particular ORM.
Some would call it "accidental complexity". Others: "tail wags the dog".

, and that's what you will have to do by hand if
not with a framework.

I have to do it by hand anyway because I have to translate the data from one
representation (a ResultSet) to another (a Widget or it's subclass or in
case of Swing to JComponent or its subclass).
I cannot see how existing ORMs (JPA included) can help me with this.

 

[Lawrence D'Oliveiro]

In practice any database access you do on Java will use JDBC.

JDBC doesn’t seem to be supported on Android.

The only question is whether you see the JDBC or it is hidden
in some higher level library.

I am using SQLite3 directly.

 

[Lawrence D'Oliveiro]

I would say that's a myth. There is no way one can create a system that is
using RDBMS without knowledge about relational databases.

And so we go back and forth in the eternal argument. There is a fundamental
“impedance mismatch†between relational databases and object-oriented
programming, and nigh-on 20 years of arguing about it has still failed to
come up with a proper solution. Trying to introduce object-oriented
databases didn’t work.

Basically, databases are a pain to work with in Java.

 

[Michal Kleczek]

And so we go back and forth in the eternal argument. There is a
fundamental “impedance mismatch†between relational databases and
object-oriented programming, and nigh-on 20 years of arguing about it has
still failed to come up with a proper solution.

To be honest I don't think there is any special "impedance mismatch" between
OO programming and relational databases. It is not different than let's say
a mismatch between OO and functional or logic programming. It is just that
some problems are easier to solve in different paradigms and a properly
architected system makes use of this fact and integrates various parts
together. I guess it is just a matter of perspective.

Sure - it would (probably) be better to have a single multiparadigm
language. Such languages exist but are not widely used (Oz is one such
example). Looks like the industry is heading towards this direction with
efforts such as Scala.
On the other hand such a language has its drawbacks as well - the main is
that it is multiparadigm (what a paradox) - so there is no single, coherent
way of creating software in such a language.

Trying to introduce
object-oriented databases didn’t work.

And that is because so called object-oriented databases actually do not
provide a key feature that a database (or rather DBMS) is supposed to
provide which is _sharing_ data (and not just persistence for a singe
application).
The whole OO-RM "impedance mismatch" has its roots in trying to use RDBMS as
a mere persistence mechanism for a OO application.

Basically, databases are a pain to work with in Java.

I don't find working with databases painful at all and I guess a lot of
people (whether they use ORMs or not) would agree with me.

 

[Lew]

What ORM does (or shoud do) is it translates one representation of data (a
ResultSet) into another (user defined).
The problem is that existing ORMs fail to do it for arbitrary chosen class
models. Instead they force a programmer to define _another_ class model that
is suited for this particular ORM.
Some would call it "accidental complexity". Others: "tail wags the dog".

I would call that "misinformation". ORMs can turn any data model into any
object model that you can do with JDBC.

Why do people keep making these false statements "JPA cannot do X"? It's very
irresponsible to give people such false information, even unethical.

Lew said:

I have to do it by hand anyway because I have to translate the data from one
representation (a ResultSet) to another (a Widget or it's subclass or in

But you have to do it with more code and tanglement with raw JDBC generally
than with the boilerplate-saving and neatly-separated way that JPA does.
There is a difference. The JPA approach, properly applied, reduces effort and
risk involved in mapping a data store to your object model.

case of Swing to JComponent or its subclass).
I cannot see how existing ORMs (JPA included) can help me with this.

Too bad for you, then.

 

[Lew]

You seem to forget that "in memory model" of data stored in a database is
already implemented - it is abstracted as ResultSet/PreparedStatement.
Please - tell me what is the value of having _another_ "in memory
representation" just to move the data from ResultSets to GUI objects.

You seem to forget that 'ResultSet' and 'PreparedStatement' are not
domain-model types.

If they are, well, then OF COURSE you don't need JPA. JPA is designed to
translate table models into DOMAIN models.

Since for some bizarre reason you don't have a need for a domain model
(whaa...?), why would you even consider an ORM?

Good programmers, who use domain models, would see value in JPA.

 

[Michal Kleczek]

You seem to forget that 'ResultSet' and 'PreparedStatement' are not
domain-model types.

If they are, well, then OF COURSE you don't need JPA. JPA is designed to
translate table models into DOMAIN models.

Since for some bizarre reason you don't have a need for a domain model
(whaa...?), why would you even consider an ORM?

Good programmers, who use domain models, would see value in JPA.

I think we start to talk past each other but let me try again.
Swing _is_ a DOMAIN model - it models a domain of GUI.

I need to "map" two DOMAIN models - accounting database schema and Swing. Is
JPA going to help me with that. If so - may I ask for some
tutorials/articles/examples?

 

[Lew]

To be honest I don't think there is any special "impedance mismatch" between
OO programming and relational databases. It is not different than let's say
a mismatch between OO and functional or logic programming. It is just that
some problems are easier to solve in different paradigms and a properly
architected system makes use of this fact and integrates various parts
together. I guess it is just a matter of perspective.

Sure - it would (probably) be better to have a single multiparadigm
language. Such languages exist but are not widely used (Oz is one such
example). Looks like the industry is heading towards this direction with
efforts such as Scala.
On the other hand such a language has its drawbacks as well - the main is
that it is multiparadigm (what a paradox) - so there is no single, coherent
way of creating software in such a language.


And that is because so called object-oriented databases actually do not
provide a key feature that a database (or rather DBMS) is supposed to
provide which is _sharing_ data (and not just persistence for a singe
application).
The whole OO-RM "impedance mismatch" has its roots in trying to use RDBMS as
a mere persistence mechanism for a OO application.


I don't find working with databases painful at all and I guess a lot of
people (whether they use ORMs or not) would agree with me.

Databases are not painful to work with. I've worked with databases my entire
career. It's the single largest part of my professional activity in Java.

With basic good programming sense and having studied how to use JDBC and JPA,
one should find database programming just fine to work with. The choice of
which one is not affected by "databases are a pain to work with".

That's not to say labor saving is useless. A master carpenter can still
choose to use a power saw where it saves effort over a hand saw, no matter how
great his skill with the latter. But he won't use the circular saw to do
detailed filigree work, nor will he try to fell a tree with a hacksaw if he
has other tools that better suit.

Now, a Dremel makes filigree work faster and easier, but it's not really "a
pain to work with" for the master without the power tool, just a longer job
that way.

 

[Lew]

I think we start to talk past each other but let me try again.
Swing _is_ a DOMAIN model - it models a domain of GUI.

Nicely disingenuous argument there.

I need to "map" two DOMAIN models - accounting database schema and Swing. Is
JPA going to help me with that. If so - may I ask for some
tutorials/articles/examples?

The GUI is not the domain model unless the GUI is the domain your program
models. If you don't understand that then nothing else we can say will make
sense.

If your program models a general ledger, for example, then the GUI is not the
domain model. How can you even make a statement or have a thought that it is?

Once you understand what a domain model is we can proceed.

 

[Michal Kleczek]

Nicely disingenuous argument there.


The GUI is not the domain model unless the GUI is the domain your program
models. If you don't understand that then nothing else we can say will
make sense.

If your program models a general ledger, for example, then the GUI is not
the
domain model.

My program does not _model_ anything. It fulfils requirements.

How can you even make a statement or have a thought that it
is?

That is exactly my point. My program is supposed to provide a GUI so that a
user can enter/modify data in a particular accounting database managed by a
RDBMS. So it's domain is _not_ accounting but user interface and
communication with RDBMS. There is no single line of code related to
accounting in it (and there should not be because this is not the purpose of
this program).
Part of classes in my program is related to UI because this is what this
program is supposed to do. Another part of my program is made of classes
that are related to communicating with RDBMS - again - because that is what
my program is supposed to do.
The fact those classes are off the shelf (both JDBC and Swing) is not
relevant.

Once you understand what a domain model is we can proceed.

I am more and more convinced it is not me who does not understand what
domain and domain model is
And I guess the lack of (deep) understanding of those is the reason why a
lot of people talk about "impedance mismatch" etc.

 

[Lawrence D'Oliveiro]

To be honest I don't think there is any special "impedance mismatch"
between OO programming and relational databases. It is not different than
let's say a mismatch between OO and functional or logic programming.

On the contrary—logic programming is also relational-based.

Also functional programming can deal more directly with entire sets of
results, and operations thereon. SQL itself can actually be a hindrance in
this, because, for example, tables and relations between them are not first-
class objects.

I don't find working with databases painful at all and I guess a lot of
people (whether they use ORMs or not) would agree with me.

Have a go at this example, then
<http://groups.google.co.nz/[email protected]>, and
see how the Java version compares.

 

[Michal Kleczek]

SQL itself can actually be a hindrance in
this, because, for example, tables and relations between them are not
first- class objects.

AFAIR Codd argued it is not needed. But I'm not an expert - if you're
interested you shoud ask at comp.databases.theory

Have a go at this example, then
<http://groups.google.co.nz/[email protected]>, and
see how the Java version compares.

What does it prove?

 

[Silvio]

Bullshit.

Besides the fact that you are vague about "usually", "trouble" and "its
worth", others' experience is the exact opposite.

JPA ORMs work great on existing databases used by multiple functional
units. They save a tonne of trouble and add very little, if properly
approached. They provide great worth. You can very quickly get to the
object model needed by the functional unit off any data source, shared
or not, whether that model differs from other consumers of the data
store or not. It saves you boilerplate, cleans up separation of layers,
and smooths the core logic of an application to use JPA.

Why would a database's pre-existence have any negative effect whatsoever
on the value of an ORM?

If anything, JPA's value is all the greater in that scenario. You focus
one set of effort on getting the mapping right, a separate set on the
logic, you actually get increased parallelization of work in a team,
especially across all those multiple consumers of the data.

That is not to say that every functional unit would use only JPA. It has
limits. Just not the ones you said.

That is your opinion. You appear to have a positive attitude towards ORM
tools while I don't. You think it is worth the trouble (as in effort) to
get your ORM to use the mapping you want for the benefits it will give
you in other areas while I usually don't (yes, I use the word "usually"
deliberately here because although I dislike ORM tools in general I
don't consider them a poor choice in all cases, just like I know you
don't consider them silver bullets).

I have seen several projects in big trouble because even TopLink (and in
one case Hibernate) experts could not get the mappings just right to get
the system to behave properly on oddly (not to say poorly) structured
databases.
In all but one of these projects parts of the database access was
rewritten to go around the ORM.

One man's bullshit is another man's bible.

 

[RedGrittyBrick]

To be honest I don't think there is any special "impedance mismatch" between
OO programming and relational databases. It is not different than let's say
a mismatch between OO and functional or logic programming. It is just that
some problems are easier to solve in different paradigms and a properly
architected system makes use of this fact and integrates various parts
together. I guess it is just a matter of perspective.

All I know is that twenty or thirty years ago you could write 4GL

define person_rec record like person.*
select * from person into person_rec where id = 42
open window person_win with form person_form
input by name person_rec.* without defaults

I would say that there is a real impedance mismatch for OO languages
that (unsurprisingly perhaps) wasn't there with RDBMS oriented languages.

 

[Lew]

That is your opinion. You appear to have a positive attitude towards ORM tools
while I don't. You think it is worth the trouble (as in effort) to get your
ORM to use the mapping you want for the benefits it will give you in other
areas while I usually don't (yes, I use the word "usually" deliberately here
because although I dislike ORM tools in general I don't consider them a poor
choice in all cases, just like I know you don't consider them silver bullets).

I have seen several projects in big trouble because even TopLink (and in one
case Hibernate) experts could not get the mappings just right to get the
system to behave properly on oddly (not to say poorly) structured databases.

So what you're saying is that you didn't raise the bridge, you lowered the
river - in other words, you had a poorly structured database and it caused
trouble for other parts of the system. And for that you blame the ORM.

Do you see a disconnect there? I do.

In all but one of these projects parts of the database access was rewritten to
go around the ORM.

I take back part of what I said. I never meant to claim that an ORM would
work well in an otherwise broken system or would somehow magically make up for
a poorly structured database. You are right.

One man's bullshit is another man's bible.

And for some, the bible is bullshit.

 

[Lawrence D'Oliveiro]

All I know is that twenty or thirty years ago you could write 4GL

define person_rec record like person.*
select * from person into person_rec where id = 42
open window person_win with form person_form
input by name person_rec.* without defaults

I suspect these would just translate into library calls with a modern
dynamic language like Python or JavaScript.

Look at the kinds of things you can do with jQuery, for example.