Hi everybody,
I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

Waiting for your comments :)

carmelo wrote:

> Hi everybody,
> I would like your opinion regarding the use of ORM in web applications
> built with GWT. I'm a little reconsider about the ORM, and I wonder
> whether it is worth to use in web applications built with GWT. 

It depends on many things but IMHO the most important is "Do you have a rich 
domain object model?" (and by "rich" I mean you have a lot of important  
processing in your OO code - not just getters and setters).
If your app is only a way to manipulate (add/update/delete) data in a 
database then I would strongly suggest _not_ using any ORM. It would only 
add a lot of Java and/or XML/whatever code without any real benefit.

Sure - you will need a framework of some kind. But IMO it shoud be a generic 
RDBMS oriented data transfer and maybe GUI/data binding one. (Similar to 
SmartGWT for example).

> What
> would be real advantages in addition to greater independence and
> portability?

Why do you think ORM gives you greater independence (from what?) and 
portability? Are you going to port your app to a non-relational DBMS?

-- 
Michal

Michal Kleczek wrote:
> carmelo wrote:
>> I would like your opinion regarding the use of ORM in web applications
>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>> whether it is worth to use in web applications built with GWT.

GWT is a graphical user interface library, right?  What possible influence on 
the choice of persistence architecture could that have?

Or am I wrong about GWT?

> It depends on many things but IMHO the most important is "Do you have a rich
> domain object model?" (and by "rich" I mean you have a lot of important
> processing in your OO code - not just getters and setters).

If not, go back and develop one before proceeding.

Now we can proceed in the certainty that you do have one.

> If your app is only a way to manipulate (add/update/delete) data in a
> database then I would strongly suggest _not_ using any ORM. It would only
> add a lot of Java and/or XML/whatever code without any real benefit.

"A lot"?  No.

Certainly no more than the JDBC code you'll need instead.

And "without any real benefit"?  Where do you get this stuff?

The real benefit, even for small projects, is the clean and manageable 
conversion between data and object models,  and a natural mapping of 
relationships to collections.

> ...

>> What would be real advantages in addition to greater independence and
>> portability?

Those aren't even advantages of an ORM.

> Why do you think ORM gives you greater independence (from what?) and
> portability? Are you going to port your app to a non-relational DBMS?

Portability is an overrated aspect of ORMs, but "relational DBMS" is no 
guarantee of portability.  When even the Oracle RDBMS deviates from the SQL 
standard, and don't even get me started on MySQL, you can bet "relational" 
won't help.  But so what?  How often have you had to change database systems 
in a project?

The advantage of an ORM is to present a persistent object model to an 
application and to relieve the application of boilerplate datastore-access 
code.  It doesn't do quite as well for bulk, or set-oriented operations, which 
after all are the stock in trade of the relational model.  In practice you'll 
need mostly ORM code (that is, regular object code) and some "raw" JDBC, 
depending on the mix of operations in your process.

I don't have any idea what "Michal" means by a "rich domain object model" that 
could be something you wouldn't have regardless, so that's a red herring.  You 
need an object model.  Period.  It needs to be as "rich" as the domain you're 
modeling.  So take that comment as advice to have such a model, not as a 
decider on the ORM question.

If you do use an ORM, use JPA (Java Persistence API)!  Don't make the mistake 
of using older specifications (e.g., "classic" Hibernate).  The Oracle Java EE 
tutorial has good information on how to do that.  You can use Hibernate (in 
its JPA mode!), EclipseLink (the /de facto/ reference implementation) or 
Apache OpenJPA.

The problem with ORMs is that people use them as mere data-access libraries. 
BRAAHHHHH!  Wrong.

Use them to maintain an object model, not a data model.  There are subtleties 
to things like EntityManager lifetime and scope that flow naturally from an 
object orientation, but will completely screw up your application (as I've 
seen on multi-million-dollar projects) if you think of an ORM as a sort of 
expanded JDBC.

A few measly hours of study should keep you out of the worst trouble.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Lew <noone@lewscanon.com> wrote:
>> carmelo wrote:
>>> I would like your opinion regarding the use of ORM in web applications
>>> built with GWT. ...
> GWT is a graphical user interface library, right?
> Or am I wrong about GWT?  [...]

http://lmgtfy.com/?q=GWT

;-)

Andreas Leitgeb wrote:
> Lew wrote:
>>> carmelo wrote:
>>>> I would like your opinion regarding the use of ORM in web applications
>>>> built with GWT. ...
>> GWT is a graphical user interface library, right?
>> Or am I wrong about GWT?  [...]
>
> http://lmgtfy.com/?q=GWT
>
> ;-)

Good one!

It was a rhetorical question, though.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 23-03-2011 04:45, carmelo wrote:
> I would like your opinion regarding the use of ORM in web applications
> built with GWT. I'm a little reconsider about the ORM, and I wonder
> whether it is worth to use in web applications built with GWT. What
> would be real advantages in addition to greater independence and
> portability?

The choice of framework for presentation layer should
not affect the choice of framework for data access layer.

If:
- your usage of data is typical CRUD of single objects
- your app is well above hello world complexity
then ORM is probably a good choice.

Arne

On 23-03-2011 07:26, Michal Kleczek wrote:
> It depends on many things but IMHO the most important is "Do you have a rich
> domain object model?" (and by "rich" I mean you have a lot of important
> processing in your OO code - not just getters and setters).

What??

Most ORM data classes are pure data classes.

> If your app is only a way to manipulate (add/update/delete) data in a
> database then I would strongly suggest _not_ using any ORM. It would only
> add a lot of Java and/or XML/whatever code without any real benefit.

What??

Together with queries then these are the areas where ORM are good.

>> What
>> would be real advantages in addition to greater independence and
>> portability?
>
> Why do you think ORM gives you greater independence (from what?) and
> portability?

Most ORM's handle the database specific stuff without the developer
needing to know.

Arne

On 23-03-2011 09:57, Lew wrote:
> Michal Kleczek wrote:
>> It depends on many things but IMHO the most important is "Do you have
>> a rich
>> domain object model?" (and by "rich" I mean you have a lot of important
>> processing in your OO code - not just getters and setters).
>
> If not, go back and develop one before proceeding.

That depends on whether the problem to be solved would
benefit from such.

>>> What would be real advantages in addition to greater independence and
>>> portability?
>
> Those aren't even advantages of an ORM.

It is certainly possible to write an ORM that does not
provide database independence, but all the major ones
for Java do provide it.

>> Why do you think ORM gives you greater independence (from what?) and
>> portability? Are you going to port your app to a non-relational DBMS?
>
> Portability is an overrated aspect of ORMs, but "relational DBMS" is no
> guarantee of portability. When even the Oracle RDBMS deviates from the
> SQL standard, and don't even get me started on MySQL, you can bet
> "relational" won't help. But so what? How often have you had to change
> database systems in a project?

It happens.

And it can be bloody expensive.

> I don't have any idea what "Michal" means by a "rich domain object
> model"

"rich" and "anemic" domain models are standard concepts - that
is either invented or at least propagated by Fowler.

> that could be something you wouldn't have regardless, so that's a
> red herring. You need an object model.  Period.

That period should be a continuation mark.

The world is a bit more complex than that.

Fowler discusses it a bit in PEAA "Domain Model" "When to Use It".

There are also the frequent case of a non object centric
usage - think statistics and aggregation.

Arne

On 11-03-23 05:45 AM, carmelo wrote:
> Hi everybody,
> I would like your opinion regarding the use of ORM in web applications
> built with GWT. I'm a little reconsider about the ORM, and I wonder
> whether it is worth to use in web applications built with GWT. What
> would be real advantages in addition to greater independence and
> portability?
> 
> Waiting for your comments :)

For me this is a surprisingly difficult recommendation to make. For most
of the decade I've been using primarily ORMs - either Hibernate or
Toplink with native APIs, or for the past 3-4 years Hibernate or Toplink
Essentials/EclipseLink with JPA. Before that, in the Java/J2EE world, it
was JDBC. I've also used iBatis/MyBatis, and raw JDBC even recently.

After the past 3-4 years of using ORMs with JPA, mostly JPA 1.0 but some
JPA 2.0, on applications of moderate load (100-300 concurrent users) and
moderate complexity (200-300 entity classes), I've come to the following
conclusions:

1. For small applications it doesn't matter what you use: JDBC, a
non-JPA mapper like MyBatis, or a full-fledged ORM with JPA like
Hibernate or EclipseLink. All of them will work, with about the same
amount of effort, and none will be more problematic than any other;

2. For larger applications I can't in all good conscience recommend
full-fledged ORMs with JPA anymore unless it's:

a. in that subset (whether it's 10 percent, or 25 percent, or whatever)
of large applications that have persistent objects and usage patterns
that are well-served by JPA (*);

b. you have a team of persistence layer developers who have substantial,
hard-earned experience with all of - the target database, JDBC, the
target application server, and the specific chosen ORM. There are dozens
of ways to get bit with JPA ORMs, and sooner or later every one of them
will get you. You'll see exceptions and encounter problems that you will
never have with JDBC.

So I'm not discounting JPA ORMs completely - I simply don't think they
are an automatic first choice. Unfortunately you (or someone on your
team) needs to have significant experience with a large JPA project
before you know whether it's a reasonable choice. It's not possible -
IMHO - to make a general recommendation that favours JPA.

AHS

* this sounds like a circular objection, but it makes more sense once
you've gone through the agony of using JPA on a large project that
really doesn't benefit from it...or is actively hindered by using it.

-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

Is JDBC worth using? I thought it was just a Java layer on top of ODBC. 
Which nobody in their right mind uses.

Arne Vajhøj wrote:

> On 23-03-2011 07:26, Michal Kleczek wrote:
>> It depends on many things but IMHO the most important is "Do you have a
>> rich domain object model?" (and by "rich" I mean you have a lot of
>> important processing in your OO code - not just getters and setters).
> 
> What??
> 
> Most ORM data classes are pure data classes.
> 

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.

>> If your app is only a way to manipulate (add/update/delete) data in a
>> database then I would strongly suggest _not_ using any ORM. It would only
>> add a lot of Java and/or XML/whatever code without any real benefit.
> 
> What??
> 
> Together with queries then these are the areas where ORM are good.
> 

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

>>> What
>>> would be real advantages in addition to greater independence and
>>> portability?
>>
>> Why do you think ORM gives you greater independence (from what?) and
>> portability?
> 
> Most ORM's handle the database specific stuff without the developer
> needing to know.

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.

-- 
Michal

On 03/23/2011 09:45 AM, carmelo wrote:
> Hi everybody,
> I would like your opinion regarding the use of ORM in web applications
> built with GWT. I'm a little reconsider about the ORM, and I wonder
> whether it is worth to use in web applications built with GWT. What
> would be real advantages in addition to greater independence and
> portability?
>
> Waiting for your comments :)

If you consider the database a serialization/deserialization tool for 
your domain objects than an ORM might be your best choice.

If the database is a deliverable on its own that will be used by other 
applications, either custom or standard stuff like reporting, analytical 
processing, ETL ..., or is pre-existing for similar reasons, then an ORM 
is usually more trouble than its worth.

On 24.3.2011 5:08, Lawrence D'Oliveiro wrote:
> Is JDBC worth using? I thought it was just a Java layer on top of ODBC. 
> Which nobody in their right mind uses.

Sun's JDBC-ODBC bridge is what you say. It is just one driver for JDBC.

JDBC itself has nothing to do with ODBC, and does not need or use it.
Native so called "thin" drivers are used mostly. The connect to the
database directly.

-- 

Q:	Why don't Scotsmen ever have coffee the way they like it?
A:	Well, they like it with two lumps of sugar.  If they drink
	it at home, they only take one, and if they drink it while
	visiting, they always take three.

Lew wrote:

> Michal Kleczek wrote:
>> carmelo wrote:
>>> I would like your opinion regarding the use of ORM in web applications
>>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>>> whether it is worth to use in web applications built with GWT.
> 
> GWT is a graphical user interface library, right?  What possible influence
> on the choice of persistence architecture could that have?
> 
> Or am I wrong about GWT?
> 
>> It depends on many things but IMHO the most important is "Do you have a
>> rich domain object model?" (and by "rich" I mean you have a lot of
>> important processing in your OO code - not just getters and setters).
> 
> If not, go back and develop one before proceeding.
> 
> Now we can proceed in the certainty that you do have one.
> 

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?

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?

-- 
Michal

Lew <noone@lewscanon.com> wrote:
> Andreas Leitgeb wrote:
>> Lew wrote:
>>>> carmelo wrote:
>>>>> I would like your opinion regarding the use of ORM in web applications
>>>>> built with GWT. ...
>>> GWT is a graphical user interface library, right?
>>> Or am I wrong about GWT?  [...]
>> http://lmgtfy.com/?q=GWT
>> ;-)
> Good one!
> It was a rhetorical question, though.

I for myself wouldn't have called GWT a GUI-lib, but that may be due
to an insufficient understanding of GWT or a differing definition of
"Gui-library" on my side.
Anyway, that's why I didn't see your answer as being rhetorical.

On Wed, 23 Mar 2011 01:45:11 -0700 (PDT), carmelo <csaffi@tiscali.it>
wrote, quoted or indirectly quoted someone who said :

>I would like your opinion regarding the use of ORM in web applications
>built with GWT. I'm a little reconsider about the ORM, and I wonder
>whether it is worth to use in web applications built with GWT. What
>would be real advantages in addition to greater independence and
>portability?
>
>Waiting for your comments :)

You might enjoy my comments at
http://mindprod.com/jgloss/sql.html#ALTERNATIVES
Also http://mindprod.com/jgloss/pod.html

Now with 64-bit Java and giant cheap VM, you might even do a project
without any POD at all, just serialise everything every once in a
while for backup. That would give you something very fast, but hard to
change.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you think it’s expensive to hire a professional to do the job, wait until you hire an amateur.
~ Red Adair

On 03/24/2011 01:16 PM, Andreas Leitgeb wrote:
> Lew<noone@lewscanon.com>  wrote:
>> Andreas Leitgeb wrote:
>>> Lew wrote:
>>>>> carmelo wrote:
>>>>>> I would like your opinion regarding the use of ORM in web applications
>>>>>> built with GWT. ...
>>>> GWT is a graphical user interface library, right?
>>>> Or am I wrong about GWT?  [...]
>>> http://lmgtfy.com/?q=GWT
>>> ;-)
>> Good one!
>> It was a rhetorical question, though.
>
> I for myself wouldn't have called GWT a GUI-lib, but that may be due
> to an insufficient understanding of GWT or a differing definition of
> "Gui-library" on my side.
> Anyway, that's why I didn't see your answer as being rhetorical.

Ooh, goody!  I have an opportunity to learn something.  (Clicking on the 
LMGTFY link you thoughtfully provided.)

Thank you.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 03/24/2011 06:35 AM, Michal Kleczek wrote:
> Lew wrote:
>
>> Michal Kleczek wrote:
>>> carmelo wrote:
>>>> I would like your opinion regarding the use of ORM in web applications
>>>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>>>> whether it is worth to use in web applications built with GWT.
>>
>> GWT is a graphical user interface library, right?  What possible influence
>> on the choice of persistence architecture could that have?
>>
>> Or am I wrong about GWT?
>>
>>> It depends on many things but IMHO the most important is "Do you have a
>>> rich domain object model?" (and by "rich" I mean you have a lot of
>>> important processing in your OO code - not just getters and setters).
>>
>> If not, go back and develop one before proceeding.
>>
>> Now we can proceed in the certainty that you do have one.
>>
>
> 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?
>
> 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?

No, but it is an antipattern to couple graphical widgets directly to the data 
in the fashion you describe.  Plus there is no framework such as you ask.

Widgets display values of objects, not data tables.  Any framework that lets 
the widgets use your data has to translate the data into an object.  That's 
what an ORM does, and that's what you will have to do by hand if not with a 
framework.

You call that "two mapping layers".  That isn't accurate.  GWT is written to 
use objects.  You map the data into the objects that it uses, using any JPA or 
other ORM tool, or via raw JDBC.  That's only a single mapping.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 03/24/2011 03:18 AM, Michal Kleczek wrote:
> Arne Vajhøj wrote:
>
>> On 23-03-2011 07:26, Michal Kleczek wrote:
>>> It depends on many things but IMHO the most important is "Do you have a
>>> rich domain object model?" (and by "rich" I mean you have a lot of
>>> important processing in your OO code - not just getters and setters).
>>
>> What??
>>
>> Most ORM data classes are pure data classes.
>>
>
> 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.

But it is the right thing to do despite your objection.

JPA adds significant benefit in the most common use cases for it.

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

Databound GUI controls are not part of GWT that I can quickly find, and they 
are not as flexible in some ways as the GWT/AWT/Swing approach.  These latter 
are based on separation of Model and View (and Controller), a strong best 
practice.  With ORMs you don't have to pick column by column out of a 
ResultSet and manually copy the data into a domain object (or widget).  With 
ORMs you construct your logic thinking in terms of object model (i.e., domain 
model) and the relationships from the domain.  The boilerplate to handle 
persistence is abstracted away from the object manipulation, making for 
cleaner, more maintainable code.  (If you use it right, as with any library.) 
  The risk of error is reduced.  The speed to working code is greatly increased.

So reduced risk, easier coding, enhanced productivity and use of best practices.


>>>> What
>>>> would be real advantages in addition to greater independence and
>>>> portability?
>>>
>>> Why do you think ORM gives you greater independence (from what?) and
>>> portability?
>>
>> Most ORM's handle the database specific stuff without the developer
>> needing to know.
>
> 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.

True.  But the ORM separates that knowledge into its own layer so that it 
doesn't commingle with or corrupt the object-oriented layers of the code.

The imnpedance match between the ORM stuff and the rest of the application is 
much better than between SQL and the rest of the application.

I've implemented the exact same apps using JDBC, monolithic DAOs with JDBC, 
and with JPA.  The JPA approach was the cleanest, most compact and easiest to 
create of the three.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 03/24/2011 04:17 AM, Silvio wrote:
> On 03/23/2011 09:45 AM, carmelo wrote:
>> Hi everybody,
>> I would like your opinion regarding the use of ORM in web applications
>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>> whether it is worth to use in web applications built with GWT. What
>> would be real advantages in addition to greater independence and
>> portability?
>>
>> Waiting for your comments :)
>
> If you consider the database a serialization/deserialization tool for your
> domain objects than an ORM might be your best choice.
>
> If the database is a deliverable on its own that will be used by other
> applications, either custom or standard stuff like reporting, analytical
> processing, ETL ..., or is pre-existing for similar reasons, then an ORM is
> usually more trouble than its worth.

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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 24-03-2011 06:35, Michal Kleczek wrote:
> Lew wrote:
>
>> Michal Kleczek wrote:
>>> carmelo wrote:
>>>> I would like your opinion regarding the use of ORM in web applications
>>>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>>>> whether it is worth to use in web applications built with GWT.
>>
>> GWT is a graphical user interface library, right?  What possible influence
>> on the choice of persistence architecture could that have?
>>
>> Or am I wrong about GWT?
>>
>>> It depends on many things but IMHO the most important is "Do you have a
>>> rich domain object model?" (and by "rich" I mean you have a lot of
>>> important processing in your OO code - not just getters and setters).
>>
>> If not, go back and develop one before proceeding.
>>
>> Now we can proceed in the certainty that you do have one.
>>
>
> 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

On 24-03-2011 03:18, Michal Kleczek wrote:
> Arne Vajhøj wrote:
>
>> On 23-03-2011 07:26, Michal Kleczek wrote:
>>> It depends on many things but IMHO the most important is "Do you have a
>>> rich domain object model?" (and by "rich" I mean you have a lot of
>>> important processing in your OO code - not just getters and setters).
>>
>> What??
>>
>> Most ORM data classes are pure data classes.
>
> 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.

>>> If your app is only a way to manipulate (add/update/delete) data in a
>>> database then I would strongly suggest _not_ using any ORM. It would only
>>> add a lot of Java and/or XML/whatever code without any real benefit.
>>
>> What??
>>
>> Together with queries then these are the areas where ORM are good.
>
> 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.

>>>> What
>>>> would be real advantages in addition to greater independence and
>>>> portability?
>>>
>>> Why do you think ORM gives you greater independence (from what?) and
>>> portability?
>>
>> Most ORM's handle the database specific stuff without the developer
>> needing to know.
>
> 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

On 23-03-2011 23:08, Lawrence D'Oliveiro wrote:
> 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

Arne Vajhøj wrote:

> On 24-03-2011 06:35, Michal Kleczek wrote:
>>
>> 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.

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.
> 
>> 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.

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

Lew wrote:

> On 03/24/2011 06:35 AM, Michal Kleczek wrote:
>> Lew wrote:
>>
>>> Michal Kleczek wrote:
>>
>> 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?
>>
>> 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?
> 
> 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.

-- 
Michal

In message <4d8bf9d8$0$23757$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> 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.

In message <imer88$u0v$1@news.onet.pl>, Michal Kleczek wrote:

> Arne Vajhøj wrote:
> 
>> Most ORM's handle the database specific stuff without the developer
>> needing to know.
> 
> 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.

Lawrence D'Oliveiro wrote:

> In message <imer88$u0v$1@news.onet.pl>, Michal Kleczek wrote:
> 
>> Arne Vajhøj wrote:
>> 
>>> Most ORM's handle the database specific stuff without the developer
>>> needing to know.
>> 
>> 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. 

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.

-- 
Michal

Michal Kleczek wrote:
> 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:
>> , and that's what you will have to do by hand if
>> not with a framework.

Michal Kleczek wrote:
> 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
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Michal Kleczek wrote:
> 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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Lew wrote:

> Michal Kleczek wrote:
>> 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.
> 

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?

-- 
Michal

On 03/25/2011 07:24 AM, Michal Kleczek wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message<imer88$u0v$1@news.onet.pl>, Michal Kleczek wrote:
>>
>>> Arne Vajhøj wrote:
>>>
>>>> Most ORM's handle the database specific stuff without the developer
>>>> needing to know.
>>>
>>> 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.
>
> 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.

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
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Michal Kleczek wrote:
> 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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Lew wrote:

> Michal Kleczek wrote:
>> 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.  

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.

-- 
Michal

In message <imhu1a$fg0$1@news.onet.pl>, Michal Kleczek wrote:

> 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.

>> 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.

Have a go at this example, then 
<http://groups.google.co.nz/groups?selm=ik1en0$gng$1@lust.ihug.co.nz>, and 
see how the Java version compares.

Lawrence D'Oliveiro wrote:

> 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

> 
>>> 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.
> 
> Have a go at this example, then
> <http://groups.google.co.nz/groups?selm=ik1en0$gng$1@lust.ihug.co.nz>, and
> see how the Java version compares.

What does it prove?

-- 
Michal

On 03/24/2011 10:36 PM, Lew wrote:
> On 03/24/2011 04:17 AM, Silvio wrote:
>> On 03/23/2011 09:45 AM, carmelo wrote:
>>> Hi everybody,
>>> I would like your opinion regarding the use of ORM in web applications
>>> built with GWT. I'm a little reconsider about the ORM, and I wonder
>>> whether it is worth to use in web applications built with GWT. What
>>> would be real advantages in addition to greater independence and
>>> portability?
>>>
>>> Waiting for your comments :)
>>
>> If you consider the database a serialization/deserialization tool for
>> your
>> domain objects than an ORM might be your best choice.
>>
>> If the database is a deliverable on its own that will be used by other
>> applications, either custom or standard stuff like reporting, analytical
>> processing, ETL ..., or is pre-existing for similar reasons, then an
>> ORM is
>> usually more trouble than its worth.
>
> 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.

On 25/03/2011 11:24, Michal Kleczek wrote:
> 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.

-- 
RGB

Silvio wrote:
> 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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

In message <4d8cac69$0$2517$db0fefd9@news.zen.co.uk>, RedGrittyBrick wrote:

> 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.

On 25-03-2011 07:06, Lawrence D'Oliveiro wrote:
> In message<imer88$u0v$1@news.onet.pl>, Michal Kleczek wrote:
>> Arne Vajhøj wrote:
>>> Most ORM's handle the database specific stuff without the developer
>>> needing to know.
>>
>> 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.

Questionable claim since most Java apps does use databases. Somehow
people does not seem to consider it a pain.

Arne

On 25-03-2011 07:24, Michal Kleczek wrote:
> Lawrence D'Oliveiro wrote:
>> In message<imer88$u0v$1@news.onet.pl>, Michal Kleczek wrote:
>>> Arne Vajhøj wrote:
>>>> Most ORM's handle the database specific stuff without the developer
>>>> needing to know.
>>>
>>> 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.
>
> To be honest I don't think there is any special "impedance mismatch" between
> OO programming and relational databases.

It has been well known for something like 20 years.

>                                   It is not different than let's say
> a mismatch between OO and functional or logic programming.

The fcat that other problem exists does not make a problem go away.

>> 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).

????

OODBMS'es support multiple apps.

Some even support multiple apps in different languages.

Arne

On 25-03-2011 05:44, Lawrence D'Oliveiro wrote:
> In message<4d8bf9d8$0$23757$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> In practice any database access you do on Java will use JDBC.
>
> JDBC doesn’t seem to be supported on Android.

It is.

http://developer.android.com/reference/java/sql/package-summary.html

>> The only question is whether you see the JDBC or it is hidden
>> in some higher level library.
>
> I am using SQLite3 directly.

Very unusual.

And unless there are some specific reasons not to use JDBC
in Android a very bad idea.

Arne

In message <imi6k2$n1h$1@news.onet.pl>, Michal Kleczek wrote:

> Lawrence D'Oliveiro wrote:
>> 
>>>> 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.
>> 
>> Have a go at this example, then
>> <http://groups.google.co.nz/groups?selm=ik1en0$gng$1@lust.ihug.co.nz>,
>> and see how the Java version compares.
> 
> What does it prove?

That you are wrong.

In message <4d8d49e4$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 25-03-2011 07:06, Lawrence D'Oliveiro wrote:
>>
>> Basically, databases are a pain to work with in Java.
> 
> Questionable claim since most Java apps does use databases. Somehow
> people does not seem to consider it a pain.

Have a go at this example, then 
<http://groups.google.co.nz/groups?selm=ik1en0$gng$1@lust.ihug.co.nz>, and 
see how the Java version compares.

On 25-03-2011 10:19, Silvio wrote:
> 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).

Lew is not the only one with that opinion.

ORM is the standard today in the Java world and plain JDBC the
exception.

>
> 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.

It is also my experience too that ORM work best with databases created
with ORM in mind and not quite as well with databases designed for
other usages in mind (like COBOL in the mid 1980's).

But I don't blame ORM for those problems.

Arne

On 25-03-2011 03:50, Michal Kleczek wrote:
> Arne Vajhøj wrote:
>
>> On 24-03-2011 06:35, Michal Kleczek wrote:
>>>
>>> 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.
>
> 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.

It was you that asked for something to map between the database
and your widgets.

And I answered that:
- ORM does not work in that context
- I don't consider that a problem since it is very bad design


>>> 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.
>
> You seem to forget that "in memory model" of data stored in a database is
> already implemented - it is abstracted as ResultSet/PreparedStatement.

A ResultSet is not in memory and are severely limited in functionality
and support mainly simple data types. A PreparedStatement does
not even contain data.

> Please - tell me what is the value of having _another_ "in memory
> representation" just to move the data from ResultSets to GUI objects.

That should be covered in basic software design.

You decouple the presentation layer from the persistence method
used.

You can cache data.

And probably a lot of other good things.

Arne

On 25-03-2011 07:40, Michal Kleczek wrote:
> 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.

No.

A domain model is a pure data model of the data you a are processing
independent of how it is displayed and stored.

Look up the definition in PEAA.

Or try Wikipdia:
   http://en.wikipedia.org/wiki/Domain_model

> 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?

No - you have a GUI and a database - we are suggesting to you that
in many cases it will be beneficial for you to put a domain model
in between.

Arne

On 25-03-2011 08:00, Michal Kleczek wrote:
> Lew wrote:
>
>> Michal Kleczek wrote:
>>> 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.
>
> My program does not _model_ anything. It fulfils requirements.

Modeling your domain is a key concept in OOD/OOP.

If you are not using OOD/OOP, then you wil not ant ORM.

I am also skeptical about whether Java is the right choice of language.

>> 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.

You are operating on data for accounting.

You should use an accounting domain model.

It would help the structure of your code.

But more importantly: you should go through a business
logic layer that implements accounting rules.

Directly editing data in an accounting database without
going through accounting business logic comes with a risk
of bring the data in an inconsistent state.

And it is also illegal in many jurisdictions.

>> 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 :)

You have beyond any doubt proved that you don't know what a domain model
(or that you use a definition that is different from what everybody
else uses, which in reality is the same).

Arne

Arne Vajhøj wrote:
>Michal Kleczek wrote:
>> My program does not _model_ anything. It fulfils requirements.

It cannot do the latter without doing the former.

The statement is ludicrous on its face.  That's like saying a musician doesn't 
play themes and melodies, he plays notes specified by sheet music.

> Modeling your domain is a key concept in OOD/OOP.
>
> If you are not using OOD/OOP, then you wil not ant ORM.
>
> I am also skeptical about whether Java is the right choice of language.

or whether programming the right choice of profession.

Arne's good advice:
> You are operating on data for accounting.
>
> You should use an accounting domain model.
>
> It would help the structure of your code.
>
> But more importantly: you should go through a business
> logic layer that implements accounting rules.
>
> Directly editing data in an accounting database without
> going through accounting business logic comes with a risk
> of bring the data in an inconsistent state.
>
> And it is also illegal in many jurisdictions.

Which ones?

That is an absolutely fascinating legal theory implied there.

Lew advised:
>>> Once you understand what a domain model is we can proceed.

Michal Kleczek wrote:
>> I am more and more convinced it is not me who does not understand what
>> domain and domain model is :)

Then you are progressively more ignorant.  Reverse that direction.

Arne Vajhøj wrote:
> You have beyond any doubt proved that you don't know what a domain model
> (or that you use a definition that is different from what everybody
> else uses, which in reality is the same).

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 03/25/2011 10:59 PM, Arne Vajhøj wrote:
> On 25-03-2011 07:40, Michal Kleczek wrote:
>> 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.
>
> No.
>
> A domain model is a pure data model of the data you a are processing
> independent of how it is displayed and stored.
>
> Look up the definition in PEAA.
>
> Or try Wikipdia:
> http://en.wikipedia.org/wiki/Domain_model
>
>> 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?
>
> No - you have a GUI and a database - we are suggesting to you that
> in many cases it will be beneficial for you to put a domain model
> in between.

Nichal, you are consistently hearing that you're asking for something that 
doesn't exist, and is an antipattern.  All you do is argue with what we're saying.

If you already know everything then you don't need anyone else's help.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

In message <4d8d520b$0$23765$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 25-03-2011 05:44, Lawrence D'Oliveiro wrote:
>
>> In message<4d8bf9d8$0$23757$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> In practice any database access you do on Java will use JDBC.
>>
>> JDBC doesn’t seem to be supported on Android.
> 
> It is.
> 
> http://developer.android.com/reference/java/sql/package-summary.html

No drivers, though.

>>> The only question is whether you see the JDBC or it is hidden
>>> in some higher level library.
>>
>> I am using SQLite3 directly.
> 
> Very unusual.

Only way to do it.

> And unless there are some specific reasons not to use JDBC
> in Android a very bad idea.

See above.

In message <4d8d53b1$0$23765$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> It is also my experience too that ORM work best with databases created
> with ORM in mind and not quite as well with databases designed for
> other usages in mind (like COBOL in the mid 1980's).

Relational databases are designed with the data semantics in mind 
(normalization and functional dependence, referential integrity etc), 
nothing more. Things like ORM have to do with the limitations of Java, they 
have no place in database design.

On 11-03-25 11:59 PM, Arne Vajh�j wrote:
> On 25-03-2011 07:40, Michal Kleczek wrote:
>> 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.
> 
> No.
> 
> A domain model is a pure data model of the data you a are processing
> independent of how it is displayed and stored.
> 
> Look up the definition in PEAA.
> 
> Or try Wikipdia:
>   http://en.wikipedia.org/wiki/Domain_model

I don't want to get embroiled in this particular sub-thread, but I feel
compelled to point out that neither of those two links, nor common
usage, suggests that a domain model is a "pure data" model. Domain
models, as the articles indicate, incorporate both behaviour and data.

A "pure data" model, I suggest, is something that you're dealing with
during physical design of your data representation and storage (*).

[ SNIP ]

AHS

* So _not_ an ERD either. These are conceptual just like domain
models...in fact ERDs _are_ also domain models.

-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

Arne Vajhøj wrote:

> On 25-03-2011 03:50, Michal Kleczek wrote:
>> Arne Vajhøj wrote:
>>
>>> On 24-03-2011 06:35, Michal Kleczek wrote:
>>>>
>>>> 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.
>>
>> 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.
> 
> It was you that asked for something to map between the database
> and your widgets.

Since the app is supposed to display data from the database this "mapping" 
(for lack of a better word) is unavoidable, don't you think?
The question is not _if_ you need it but "how to implement it?".

> 
> And I answered that:
> - ORM does not work in that context

I read it "in the context of implementing GUIs that display data from a 
relational database ORM is useless".

> - I don't consider that a problem since it is very bad design
> 

My design in the context of this discussion is ( an arrow means "depends 
on"):
[JDBC and database schema] <--- X ---> [GUI library]

X being something of our interest in this thread.

What is wrong with this design?

[snip]
> 
>> Please - tell me what is the value of having _another_ "in memory
>> representation" just to move the data from ResultSets to GUI objects.
> 
> That should be covered in basic software design.
> 
> You decouple the presentation layer from the persistence method
> used.

Again - they are decoupled - see above.
Or maybe we define "coupling" differently.

> 
> You can cache data.
> 

True.
OTOH you can cache data using other means as well - for example by having a 
caching JDBC driver on top of a "real" one (a decorator pattern). You don't 
need ORM to cache data (since they are orthogonal concerns).

> And probably a lot of other good things.

What are they?

-- 
Michal

Lew wrote:

> 
> Nichal, you are consistently hearing that you're asking for something that
> doesn't exist, and is an antipattern.  
> All you do is argue with what we're
> saying.
> 
> If you already know everything then you don't need anyone else's help.
> 

I didn't ask for help. I am discussing - thought discussion groups are for 
er... discussions. If you do not want to discuss - just don't reply - it's 
that easy.

-- 
Michal

Michal Kleczek wrote:
> Since the app is supposed to display data from the database this "mapping"
> (for lack of a better word) is unavoidable, don't you think?
> The question is not _if_ you need it but "how to implement it?".

You mean the /discussion/ is about how to implement it.  After all, as you so 
helpfully pointed out, you aren't asking for help, you're having a discussion. 
  Right?

Several people have addressed that matter in this thread but I haven't seen 
you reply to their points yet.

>> And I answered that:
>> - ORM does not work in that context
>
> I read it "in the context of implementing GUIs that display data from a
> relational database ORM is useless".

Hadn't replied until now, that is, but one might suggest that you really 
aren't contributing to the discussion much with that reply.

>> - I don't consider that a problem since it is very bad design

> My design in the context of this discussion is ( an arrow means "depends
> on"):
> [JDBC and database schema]<--- X --->  [GUI library]
>
> X being something of our interest in this thread.
>
> What is wrong with this design?

This discussion is getting boring.  You argue with everyone without really 
showing that you understand what is said, you ignore some of what people say 
that is relevant, you deny that you want help but you keep asking for help.

You ask questions that appear to be sincere requests for information or 
opinion, only to make replies to show off how wrong the entire rest of the 
newsgroup is.  When someone tries to engage you in the conversation, rather 
than reply to the points you say, "If you do not want to discuss - just don't 
reply - it's that easy."  Why would you be so rude if, as you claim, your goal 
is to engage in discussion?

To answer your question, there isn't enough information in the question to 
deem anything wrong with the fragment of design you show.

The actual things you've asked for, some magic third-party library to break 
encapsulation and the innate MVC model of the libraries in question in order 
to directly couple the things you ask about in a way they never intended, 
don't exist, as many folks have already told you several times.  I guess you 
weren't listening.  Please, Oh Great Master of Programming, write your own.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

In message <4d8d5843$0$23762$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> Directly editing data in an accounting database without
> going through accounting business logic comes with a risk
> of bring the data in an inconsistent state.
> 
> And it is also illegal in many jurisdictions.

What is their legal definition of the “accounting business logic” layer, 
then, if not the code that is doing the “direct editing” of the accounting 
data?

On 03/26/2011 03:47 AM, Arne Vajhøj wrote:
> On 25-03-2011 10:19, Silvio wrote:
>> 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).
>
> Lew is not the only one with that opinion.
>
> ORM is the standard today in the Java world and plain JDBC the
> exception.

I am not sure who defines what "the standard" is but you may be right. 
But I do not find that an argument in favor of ORM on its own. EJB has 
been considered the standard for years and I try to avoid them as much 
as possible also.

I am doing different things than most people, I guess. But that is what 
most people will say...

>
>>
>> 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.
>
> It is also my experience too that ORM work best with databases created
> with ORM in mind and not quite as well with databases designed for
> other usages in mind (like COBOL in the mid 1980's).
>
> But I don't blame ORM for those problems.

Me neither. I just said that in such cases an ORM could very well be a 
poor choice.

I rarely write database access code that targets specific tables or 
table structures. For my purposes a RDBMS is just one of several types 
of data sources for analysis and reporting. It may also be a type of 
data storage system.

Generic database access code is not something that is supported very 
well by ORMs, IMHO.

Silvio

>
> Arne

In message <4d90373e$0$81476$e4fe514c@news.xs4all.nl>, Silvio wrote:

> I rarely write database access code that targets specific tables or
> table structures. For my purposes a RDBMS is just one of several types
> of data sources for analysis and reporting. It may also be a type of
> data storage system.

What an odd thing to say. The whole point about relational databases is that 
their structure is supposed to reflect the innate logical structure of the 
data you’re dealing with—the actual semantics of your business app. To want 
to abstract away from that would be to abstract away from the very details 
of your business.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>
> What an odd thing to say. The whole point about relational databases is that 
> their structure is supposed to reflect the innate logical structure of the 
> data you’re dealing with—the actual semantics of your business app.

No, the main point of relational databases is to store, change and search
large amounts of data in a way that both protects the integrity of the data
and has good performance.

A good match between the business semantics and the relational data-model
is certainly a good way to protect the developers' sanity (such as it is)
but that's not the purpose or intent of a relational database. Database
normalisation will often serve to move the data-model _away_ from the
semantic model, and relational DB concepts such as cursors, row locks, 
foreign keys and joins are downright alien to the semantic model.

-- 
Leif Roar Moldskred

On 03/28/2011 09:26 AM, Lawrence D'Oliveiro wrote:
> In message<4d90373e$0$81476$e4fe514c@news.xs4all.nl>, Silvio wrote:
>
>> I rarely write database access code that targets specific tables or
>> table structures. For my purposes a RDBMS is just one of several types
>> of data sources for analysis and reporting. It may also be a type of
>> data storage system.
>
> What an odd thing to say. The whole point about relational databases is that
> their structure is supposed to reflect the innate logical structure of the
> data you’re dealing with—the actual semantics of your business app. To want
> to abstract away from that would be to abstract away from the very details
> of your business.

True. But there are classes of systems other than generic database 
management tools for which a relational database is still a generic beast.

One group consists of standard software systems (in the sense of not 
custom made and therefore generic) for things like reporting, analysis, 
ETL, etc.

Another group consists of systems where users can define complex 
entities that need to be (generically) transformed into relational 
structures.

In my case users can define/design things like:

-research panels with user defined variable structures and portal user 
interfaces
-research questionnaires/surveys where questions have to be mapped to on 
screen representations as well as to data representations
-reports and reporting dashboards that have to be able to process data 
from one of the above or from third party sources.

I do not only have to handle the RDBMS in a generic way. I use a generic 
data access interface that could be mapped onto a RDBMS but in many 
cases it can also be mapped to formats like SPSS, Triple-S, DBF, Excel, 
CSV etc.

So it just depends on what you are doing.

Lawrence D'Oliveiro wrote:

> In message <4d90373e$0$81476$e4fe514c@news.xs4all.nl>, Silvio wrote:
> 
>> I rarely write database access code that targets specific tables or
>> table structures. For my purposes a RDBMS is just one of several types
>> of data sources for analysis and reporting. It may also be a type of
>> data storage system.
> 
> What an odd thing to say. The whole point about relational databases is
> that their structure is supposed to reflect the innate logical structure
> of the data you’re dealing with—the actual semantics of your business app.

Of course. But that does not mean that your business app cannot be composed 
of parts that are schema independent.

> To want to abstract away from that would be to abstract away from the very
> details of your business.

Sometimes you need to abstract away the schema. Would you design an ORM tool 
with a particular schema in mind?

-- 
Michal

In message <impn7h$2sd$1@news.onet.pl>, Michal Kleczek wrote:

> Would you design an ORM tool with a particular schema in mind?

I wouldn’t use ORM at all. Java already makes it difficult to deal with 
databases, without adding unnecessary work like that.

Lawrence D'Oliveiro wrote:

> In message <impn7h$2sd$1@news.onet.pl>, Michal Kleczek wrote:
> 
>> Would you design an ORM tool with a particular schema in mind?
> 
> I wouldn’t use ORM at all. 

Neither would I :)
But you snipped context (wonder why). Anyway -how about a reporting tool - 
would you design it with a particular schema in mind?

-- 
Michal

On 03/28/2011 06:17 AM, Michal Kleczek wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message<4d90373e$0$81476$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>
>>> I rarely write database access code that targets specific tables or
>>> table structures. For my purposes a RDBMS is just one of several types
>>> of data sources for analysis and reporting. It may also be a type of
>>> data storage system.
>>
>> What an odd thing to say. The whole point about relational databases is
>> that their structure is supposed to reflect the innate logical structure
>> of the data you’re dealing with—the actual semantics of your business app.

That's not true.  The "whole point" about relational databases is to NOT 
reflect the domain structure, but to store data as tables of rows.  Prior to 
the relational model databases did try to store domain models and it led to 
problems, problems so widespread and fundamental that hardly anyone remembers 
non-relational databases.

The relational model intentionally breaks the domain model structure into 
normal forms of just data, internally devoid of semantics.  The genius of the 
relational model is that it separated the domain model from the data model, 
leaving the mapping between them to a separate layer, the business logic.  As 
a result, database models capture the data from the domain model, but they 
don't reflect the domain model directly.

By design the relational model imposes on the business logic the 
responsibility to map the data model to the domain model.  ORMs are supposed 
to help with that responsibility.

> Of course. But that does not mean that your business app cannot be composed
> of parts that are schema independent.
>
>> To want to abstract away from that would be to abstract away from the very
>> details of your business.
>
> Sometimes you need to abstract away the schema. Would you design an ORM tool
> with a particular schema in mind?

Would you design a relational schema with only one application in mind?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Lew wrote:

> On 03/28/2011 06:17 AM, Michal Kleczek wrote:
>> Lawrence D'Oliveiro wrote:
>>
>>> In message<4d90373e$0$81476$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>
>>>> I rarely write database access code that targets specific tables or
>>>> table structures. For my purposes a RDBMS is just one of several types
>>>> of data sources for analysis and reporting. It may also be a type of
>>>> data storage system.
>>>
>>> What an odd thing to say. The whole point about relational databases is
>>> that their structure is supposed to reflect the innate logical structure
>>> of the data you’re dealing with—the actual semantics of your business
>>> app.
> 
> That's not true.  The "whole point" about relational databases is to NOT
> reflect the domain structure, but to store data as tables of rows.  

No. RDBMSes do not store data as tables of rows. They _present_ data as 
tables of rows (or rather - relations and tuples). The "whole point" about 
relational databases is to introduce a "logical model" and abstract away 
from "physical model".
What's more - the "whole point" of designing a database schema is to capture 
as much relevant information about the domain as possible - the single fact 
that you give a name to a relation or specify a constraint means you 
_reflect_ the domain structure and _implement_ business logic.
If that was not the case all database schemas would be equivalent (and EAV 
would be the most used one).

> Prior
> to the relational model databases did try to store domain models and it
> led to problems, problems so widespread and fundamental that hardly anyone
> remembers non-relational databases.

I've never heard hierarchical databases tried to store domain models. Could 
you point me to some material backing this statement?

> 
> The relational model intentionally breaks the domain model structure into
> normal forms of just data, internally devoid of semantics.  The genius of
> the relational model is that it separated the domain model from the data
> model,
> leaving the mapping between them to a separate layer, the business logic. 
> As a result, database models capture the data from the domain model, but
> they don't reflect the domain model directly.

Of course they don't. Neither do class models of applications using a 
database.

> 
> By design the relational model imposes on the business logic the
> responsibility to map the data model to the domain model.  

At least we agree that a data model and an (OO) application class model are 
different and have to be mapped.
But the question of whether one or the other is _the_ domain model cannot be 
answered - they are equal. Furthermore - every application accessing the 
same database has _its own_ class model that is suited for _this_ 
application.

> ORMs are
> supposed to help with that responsibility.

But they fail to do so because they require a class model and a database 
model to too closely mirror each other and this contradicts their purpose.

> 
>> Of course. But that does not mean that your business app cannot be
>> composed of parts that are schema independent.
>>
>>> To want to abstract away from that would be to abstract away from the
>>> very details of your business.
>>
>> Sometimes you need to abstract away the schema. Would you design an ORM
>> tool with a particular schema in mind?
> 
> Would you design a relational schema with only one application in mind?
> 

It depends :)
Why this question?

-- 
Michal

Michal Kleczek wrote:
> Lew wrote:
>> That's not true.  The "whole point" about relational databases is to NOT
>> reflect the domain structure, but to store data as tables of rows.

> No. RDBMSes do not store data as tables of rows. They _present_ data as
> tables of rows (or rather - relations and tuples). The "whole point" about

Sure.

> relational databases is to introduce a "logical model" and abstract away
> from "physical model".

Well, I agree with that but still stand by my picture.  Both "whole points", 
and why I put the expression in quotes, are far from the whole point.  Both 
are valid points from a programmer's toolbox of ontologies.

> What's more - the "whole point" of designing a database schema is to capture
> as much relevant information about the domain as possible - the single fact
> that you give a name to a relation or specify a constraint means you
> _reflect_ the domain structure and _implement_ business logic.
> If that was not the case all database schemas would be equivalent (and EAV
> would be the most used one).

Yes, you are right.

>> Prior
>> to the relational model databases did try to store domain models and it
>> led to problems, problems so widespread and fundamental that hardly anyone
>> remembers non-relational databases.

> I've never heard hierarchical databases tried to store domain models. Could
> you point me to some material backing this statement?

I was putting a touch of poetic license in there, and also I was thinking of 
network-model databases.  These tried to capture all the relevant 
relationships directly, rather than in the ad hoc fashion of the (pure) 
relational model.

But you are correct - all these representations whether object or data are 
reflections of the domain model, essentially projections of an /n/-dimensional 
model space to an /m/-dimensional data or object model, where /m < n/. 
Poetically speaking, of course.

We're all six blind men examining the elephant here.

>> The relational model intentionally breaks the domain model structure into
>> normal forms of just data, internally devoid of semantics.  The genius of
>> the relational model is that it separated the domain model from the data
>> model,
>> leaving the mapping between them to a separate layer, the business logic.
>> As a result, database models capture the data from the domain model, but
>> they don't reflect the domain model directly.

> Of course they don't. Neither do class models of applications using a
> database.

You are correct.

>> By design the relational model imposes on the business logic the
>> responsibility to map the data model to the domain model.

> At least we agree that a data model and an (OO) application class model are
> different and have to be mapped.

I agree with nearly all of what you're saying.

> But the question of whether one or the other is _the_ domain model cannot be
> answered - they are equal. Furthermore - every application accessing the
> same database has _its own_ class model that is suited for _this_
> application.

Indeed.

>> ORMs are supposed to help with that responsibility.

> But they fail to do so because they require a class model and a database
> model to too closely mirror each other and this contradicts their purpose.

They don't require that.  This is what's not in "almost all".  It's a bit 
tedious to construct an example, but for the category of projects for which 
JPA (I excoriate other ORMs) suits, it imposes no restraints on the data model 
whatsoever, and the entity model is constrained by the semantic model and 
somewhat by the data model, which transitively depends on the semantic model. 
  I don't know what you mean by "too closely", but I really cannot conceive of 
a normal business-type project where JPA plays a role in deciding the object 
or data models.  On the contrary, those flow from normal design and 
development processes, and JPA is an implementation tool to connect the two.

....

>>> Sometimes you need to abstract away the schema. Would you design an ORM
>>> tool with a particular schema in mind?

>> Would you design a relational schema with only one application in mind?

> It depends :)
> Why this question?

To show that it's a similar question, and that the answer is, "It depends."

Usually a relational schema for a larger project supports more than one 
application, e.g., inventory and order fulfillment share data.  The parts of 
the system interact with the parts of the schema that they need, and the 
schema serves all parts.

Likewise an ORM tool assumes a kind of meta-schema - the (appearance of) a 
relational data store.  It's as general for the intended use as it needs to 
be, that is, it allows all kinds of things that fit its meta-schema.  Just 
like a relational database schema permits all kinds of things, not all known 
at the beginning, if they fit.

Using JDBC on a per-project basis is designing an ORM tool for one particular 
database schema.  That tool is your data-access layer for that project.

Both are excellent questions, for their respective domains of discourse.  They 
are part of the design and implementation question list one must generate for 
a project.

You make well-reasoned, empowering points.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Lew wrote:

> Michal Kleczek wrote:
>> Lew wrote:
>>> That's not true.  The "whole point" about relational databases is to NOT
>>> reflect the domain structure, but to store data as tables of rows.
> 
>> No. RDBMSes do not store data as tables of rows. They _present_ data as
>> tables of rows (or rather - relations and tuples). The "whole point"
>> about
> 
> Sure.
> 
>> relational databases is to introduce a "logical model" and abstract away
>> from "physical model".
> 
> Well, I agree with that but still stand by my picture.  Both "whole
> points",
> and why I put the expression in quotes, are far from the whole point. 
> Both are valid points from a programmer's toolbox of ontologies.
> 
>> What's more - the "whole point" of designing a database schema is to
>> capture as much relevant information about the domain as possible - the
>> single fact that you give a name to a relation or specify a constraint
>> means you _reflect_ the domain structure and _implement_ business logic.
>> If that was not the case all database schemas would be equivalent (and
>> EAV would be the most used one).
> 
> Yes, you are right.
> 
>>> Prior
>>> to the relational model databases did try to store domain models and it
>>> led to problems, problems so widespread and fundamental that hardly
>>> anyone remembers non-relational databases.
> 
>> I've never heard hierarchical databases tried to store domain models.
>> Could you point me to some material backing this statement?
> 
> I was putting a touch of poetic license in there, and also I was thinking
> of
> network-model databases.  These tried to capture all the relevant
> relationships directly, rather than in the ad hoc fashion of the (pure)
> relational model.
> 
> But you are correct - all these representations whether object or data are
> reflections of the domain model, essentially projections of an
> /n/-dimensional model space to an /m/-dimensional data or object model,
> where /m < n/. Poetically speaking, of course.
> 
> We're all six blind men examining the elephant here.
> 
>>> The relational model intentionally breaks the domain model structure
>>> into
>>> normal forms of just data, internally devoid of semantics.  The genius
>>> of the relational model is that it separated the domain model from the
>>> data model,
>>> leaving the mapping between them to a separate layer, the business
>>> logic. As a result, database models capture the data from the domain
>>> model, but they don't reflect the domain model directly.
> 
>> Of course they don't. Neither do class models of applications using a
>> database.
> 
> You are correct.
> 
>>> By design the relational model imposes on the business logic the
>>> responsibility to map the data model to the domain model.
> 
>> At least we agree that a data model and an (OO) application class model
>> are different and have to be mapped.
> 
> I agree with nearly all of what you're saying.

So if we are mostly in agreement I'm going to try to move further :)

> 
>> But the question of whether one or the other is _the_ domain model cannot
>> be answered - they are equal. Furthermore - every application accessing
>> the same database has _its own_ class model that is suited for _this_
>> application.
> 
> Indeed.
> 
>>> ORMs are supposed to help with that responsibility.
> 
>> But they fail to do so because they require a class model and a database
>> model to too closely mirror each other and this contradicts their
>> purpose.
> 
> They don't require that.  This is what's not in "almost all".  It's a bit
> tedious to construct an example, but for the category of projects for
> which JPA (I excoriate other ORMs) suits, it imposes no restraints on the
> data model whatsoever, and the entity model is constrained by the semantic
> model and somewhat by the data model, which transitively depends on the
> semantic model.
>   I don't know what you mean by "too closely", but I really cannot
>   conceive of
> a normal business-type project where JPA plays a role in deciding the
> object
> or data models.  On the contrary, those flow from normal design and
> development processes, and JPA is an implementation tool to connect the
> two.
> 

(BE WARNED: below you're going to find controversial ideas described by a 
lot of people as "bad engineering practices" - but please read the whole 
thing before criticizing :) )

Imagine you have two models: a database schema S and a class library C. Both 
are completely independent and both capture a certain aspect of the system 
under design.
I would consider ORM useful if it helps me to "map" one to another to create 
an application that meets some set of requirements. To be precise "mapping" 
means moving data from the db to instances of classes from library C 
(potentially creating instances of those classes) and back to save the state 
of those instances in the database.

Now imagine schema S desribes an accounting database and library C - classes 
implementing neural network computations. There is no single class related 
to accounting in the library C. The only connection between accounting and 
neural networks is the application under design - it provides the necessary 
context. The question: does it make sense to use ORM to do the "mapping"?

Then imagine library C is a GUI widget library. Does it make sense to use 
ORM in this case? It would be sooo convinient to be able to write:

void main(String[] args) {
  EntityManager em = ...;
  
  JFrame f = em.find(JFrame.class, "main");
  f.show();

  while(true) {}
}

and use ORM parametrization and "magic" to map S (accounting database 
schema) and C (UI classes) to have accounting UI without pain :)
(Yes - I know the above is taking ORM to the extreme - but it is _just_ to 
illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas to 
_arbitrary_ class models).

What supporters of JPA say instead is that it is a "good practice" to create 
another class model B (so called "business model") then use ORM to "map" the 
database schema to class model B and then write more code to "map" class 
model B to class model C. The problem is that there is no application 
specific "business logic" I could put into B since all of it is already 
implemented in C.

There is even more "insanity" - once we have class model B - we start using 
data binding library based on reflection (Java Beans conventions) to move 
data from instances of B to instances of C - loosing the last inteded 
benefits of having B (namely type safety).

[snip]
> 
> Using JDBC on a per-project basis is designing an ORM tool for one
> particular
> database schema.  That tool is your data-access layer for that project.

As soon as I get an ORM tool capable of mapping to _arbitrary_ class model I 
am going to use it wholeheartedly. Until that happens I think I would just 
stick to more lightweight tools such as Spring JDBC that resolves some 
inconvinience of JDBC (connection/resource management etc.) while still 
giving me freedom with designing my class model.

-- 
Michal

Michal Kleczek wrote:
> Now imagine schema S desribes an accounting database and library C - clas=
ses
> implementing neural network computations. There is no single class relate=
d
> to accounting in the library C. The only connection between accounting an=
d
> neural networks is the application under design - it provides the necessa=
ry
> context. The question: does it make sense to use ORM to do the "mapping"?
>

It depends.

If you have entities that are modeled in the database, it makes sense.

> Then imagine library C is a GUI widget library. Does it make sense to use
> ORM in this case? It would be sooo convinient to be able to write:
>
> void main(String[] args) {
> =A0 EntityManager em =3D ...;
>
> =A0 JFrame f =3D em.find(JFrame.class, "main");
> =A0 f.show();
>
> =A0 while(true) {}
>
> }
>
> and use ORM parametrization and "magic" to map S (accounting database
> schema) and C (UI classes) to have accounting UI without pain :)
> (Yes - I know the above is taking ORM to the extreme - but it is _just_ t=
o
> illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas t=
o
> _arbitrary_ class models).
>

If you don't have an ORM map to intermediate entities, then you have
to manually map to those entities.

If you "map" directly from the DB to your widget, you are still
mapping to the entity represented by the widgete.  Since you are dead
set against modeling that domain entity as anything other than a set
of related tables or a set of related widgets, you're right, an ORM
will be of no use.    But that's not because you are saving any
mapping effort.  You've just traded the effort of an entity model for
the sometimes greater effort of maintaining widget-to-table mappings
by hand.

> What supporters of JPA say instead is that it is a "good practice" to cre=
ate
> another class model B (so called "business model") then use ORM to "map" =
the
> database schema to class model B and then write more code to "map" class
> model B to class model C. The problem is that there is no application
> specific "business logic" I could put into B since all of it is already
> implemented in C.
>

Fine.

> There is even more "insanity" - once we have class model B - we start usi=
ng
>

It is appropriate that you put "insanity" in quotes here, since the
real thing you attempt to disparage is not actually insane.

> data binding library based on reflection (Java Beans conventions) to move
> data from instances of B to instances of C - loosing the last inteded
> benefits of having B (namely type safety).
>

Why would you do that?  It's not a JPA thing.

>> Using JDBC on a per-project basis is designing an ORM tool for one
>> particular
>> database schema. =A0That tool is your data-access layer for that project=
..
>
> As soon as I get an ORM tool capable of mapping to _arbitrary_ class mode=
l I
> am going to use it wholeheartedly. Until that happens I think I would jus=
t
>

You mean like JPA, then.

Well, strictly speaking what it maps to is arbitrary *entity* models,
which is far more useful.

It actually is not useful to map to arbitrary class models.  Just as
'enum' doesn't handle every type-safe enumeration scenario, JPA is not
even intended to handle *every* data-access scenario.

THERE IS NO LIBRARY THAT WILL DO WHAT YOU ASK, NOR CAN THERE EVER BE.

That's like saying, "Until clean energy gives me a perpetual-motion
machine I will stay with fossil fuels."  It's a ridiculous
precondition.

JPA is only intended for the subset of mappings that make sense.
You're asking for one that doesn't make sense, then deriding ORMs for
not supporting it.  So don't use an ORM.  It's not even meant for
everything.

So, "It doesn't do everything" is a bullshit complaint.

> stick to more lightweight tools such as Spring JDBC that resolves some
> inconvinience of JDBC (connection/resource management etc.) while still
> giving me freedom with designing my class model.
>

Making JPanel a domain object for an accounting system is an abuse of
freedom.  But you go, girl!

--
Lew

Lew wrote:

> Michal Kleczek wrote:
>> Now imagine schema S desribes an accounting database and library C -
>> classes implementing neural network computations. There is no single
>> class related to accounting in the library C. The only connection between
>> accounting and neural networks is the application under design - it
>> provides the necessary context. The question: does it make sense to use
>> ORM to do the "mapping"?
>>
> 
> It depends.
> 
> If you have entities that are modeled in the database, it makes sense.
> 
>> Then imagine library C is a GUI widget library. Does it make sense to use
>> ORM in this case? It would be sooo convinient to be able to write:
>>
>> void main(String[] args) {
>> EntityManager em = ...;
>>
>> JFrame f = em.find(JFrame.class, "main");
>> f.show();
>>
>> while(true) {}
>>
>> }
>>
>> and use ORM parametrization and "magic" to map S (accounting database
>> schema) and C (UI classes) to have accounting UI without pain :)
>> (Yes - I know the above is taking ORM to the extreme - but it is _just_
>> to illustrate the weaknesses of current ORMs in mapping _arbirary_
>> schemas to _arbitrary_ class models).
>>
> 
> If you don't have an ORM map to intermediate entities, then you have
> to manually map to those entities.
> 
> If you "map" directly from the DB to your widget, you are still
> mapping to the entity represented by the widgete.  Since you are dead
> set against modeling that domain entity as anything other than a set
> of related tables or a set of related widgets, you're right, an ORM
> will be of no use.    

That's not the point. As we agreed before - each application has its own 
class model. One application does some computing using neural networks - its 
class model will be neural networks related. Another app's purpose is to 
present a user with a GUI - its class model will be GUI widgets.

To make ORM useful it has to support both without requiring creating 
_another_ class model just to be able to use ORM.

> But that's not because you are saving any
> mapping effort.  You've just traded the effort of an entity model for
> the sometimes greater effort of maintaining widget-to-table mappings
> by hand.

But mapping from "entity model" to widgets has the same cost as mapping DB 
schema to widgets. So having "entity model" incures additional cost of 
mapping between it and DB schema (and additionally maintaining "entity 
model" itself).

> 
>> What supporters of JPA say instead is that it is a "good practice" to
>> create another class model B (so called "business model") then use ORM to
>> "map" the database schema to class model B and then write more code to
>> "map" class model B to class model C. The problem is that there is no
>> application specific "business logic" I could put into B since all of it
>> is already implemented in C.
>>
> 
> Fine.
> 
>> There is even more "insanity" - once we have class model B - we start
>> using
>>
> 
> It is appropriate that you put "insanity" in quotes here, since the
> real thing you attempt to disparage is not actually insane.
> 
>> data binding library based on reflection (Java Beans conventions) to move
>> data from instances of B to instances of C - loosing the last inteded
>> benefits of having B (namely type safety).
>>
> 
> Why would you do that?  It's not a JPA thing.
> 

But that is a very common practice - once you have a set of Java beans you 
use Java Beans based data binding tool to display data from those Java 
beans.

>>> Using JDBC on a per-project basis is designing an ORM tool for one
>>> particular
>>> database schema.  That tool is your data-access layer for that project.
>>
>> As soon as I get an ORM tool capable of mapping to _arbitrary_ class
>> model I am going to use it wholeheartedly. Until that happens I think I
>> would just
>>
> 
> You mean like JPA, then.
> 
> Well, strictly speaking what it maps to is arbitrary *entity* models,
> which is far more useful.
> 

What I'm doing here is actually questioning the need of such "entity 
models". I'm trying to prove that they exist solely because a designer made 
a decision to use ORM. Hence I talk about accidental complexity.

> It actually is not useful to map to arbitrary class models.  Just as
> 'enum' doesn't handle every type-safe enumeration scenario, JPA is not
> even intended to handle *every* data-access scenario.

I would say more - its usfullnes is very limited at all.

> 
> THERE IS NO LIBRARY THAT WILL DO WHAT YOU ASK, NOR CAN THERE EVER BE.
> 

JPA is marketed as such unfortunatelly.

OTOH there are libraries that will help me to do it (the mapping) instead of 
making it more difficult.

-- 
Michal

In message <imq7cm$b2r$1@news.onet.pl>, Michal Kleczek wrote:

> Now imagine schema S desribes an accounting database and library C -
> classes implementing neural network computations.
> 
> Then imagine library C is a GUI widget library.

You mean C is both a library of GUI widgets and a library implementing 
application logic?

I would not do things that way.

> What supporters of JPA say instead is that it is a "good practice" to
> create another class model B (so called "business model") then use ORM to
> "map" the database schema to class model B and then write more code to
> "map" class model B to class model C. The problem is that there is no
> application specific "business logic" I could put into B since all of it
> is already implemented in C.

If C is the GUI, then there is a case for putting the application logic into 
a lower layer B.

In message <7rudncLSMpvB0A3QnZ2dnUVZ876dnZ2d@telenor.com>, Leif Roar 
Moldskred wrote:

> Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>>
>> What an odd thing to say. The whole point about relational databases is
>> that their structure is supposed to reflect the innate logical structure
>> of the data you’re dealing with—the actual semantics of your business
>> app.
> 
> No, the main point of relational databases is to store, change and search
> large amounts of data in a way that both protects the integrity of the
> data and has good performance.

But that “integrity” is part of the semantics of the data.

> A good match between the business semantics and the relational data-model
> is certainly a good way to protect the developers' sanity (such as it is)
> but that's not the purpose or intent of a relational database. Database
> normalisation will often serve to move the data-model _away_ from the
> semantic model, and relational DB concepts such as cursors, row locks,
> foreign keys and joins are downright alien to the semantic model.

On the contrary: normalization, foreign keys and joins are part of the 
mathematical formalism that is specifically designed to express that 
semantics.

Lawrence D'Oliveiro wrote:

> In message <imq7cm$b2r$1@news.onet.pl>, Michal Kleczek wrote:
> 
>> Now imagine schema S desribes an accounting database and library C -
>> classes implementing neural network computations.
>> 
>> Then imagine library C is a GUI widget library.
> 
> You mean C is both a library of GUI widgets and a library implementing
> application logic?
> 
> I would not do things that way.
> 
>> What supporters of JPA say instead is that it is a "good practice" to
>> create another class model B (so called "business model") then use ORM to
>> "map" the database schema to class model B and then write more code to
>> "map" class model B to class model C. The problem is that there is no
>> application specific "business logic" I could put into B since all of it
>> is already implemented in C.
> 
> If C is the GUI, then there is a case for putting the application logic
> into a lower layer B.

http://en.wikipedia.org/wiki/No_true_Scotsman

-- 
Michal

On 03/29/2011 12:53 AM, Michal Kleczek wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message<imq7cm$b2r$1@news.onet.pl>, Michal Kleczek wrote:
>>
>>> Now imagine schema S desribes an accounting database and library C -
>>> classes implementing neural network computations.
>>>
>>> Then imagine library C is a GUI widget library.
>>
>> You mean C is both a library of GUI widgets and a library implementing
>> application logic?
>>
>> I would not do things that way.
>>
>>> What supporters of JPA say instead is that it is a "good practice" to
>>> create another class model B (so called "business model") then use ORM to
>>> "map" the database schema to class model B and then write more code to
>>> "map" class model B to class model C. The problem is that there is no
>>> application specific "business logic" I could put into B since all of it
>>> is already implemented in C.
>>
>> If C is the GUI, then there is a case for putting the application logic
>> into a lower layer B.
>
> http://en.wikipedia.org/wiki/No_true_Scotsman

He's used that fallacy before, but this wasn't one of those times.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 03/28/2011 04:53 PM, Michal Kleczek wrote:
>
[snip]
>
> (BE WARNED: below you're going to find controversial ideas described by a
> lot of people as "bad engineering practices" - but please read the whole
> thing before criticizing :) )
>
> Imagine you have two models: a database schema S and a class library C. Both
> are completely independent and both capture a certain aspect of the system
> under design.
> I would consider ORM useful if it helps me to "map" one to another to create
> an application that meets some set of requirements. To be precise "mapping"
> means moving data from the db to instances of classes from library C
> (potentially creating instances of those classes) and back to save the state
> of those instances in the database.
>
> Now imagine schema S desribes an accounting database and library C - classes
> implementing neural network computations. There is no single class related
> to accounting in the library C. The only connection between accounting and
> neural networks is the application under design - it provides the necessary
> context. The question: does it make sense to use ORM to do the "mapping"?
>
> Then imagine library C is a GUI widget library. Does it make sense to use
> ORM in this case? It would be sooo convinient to be able to write:
>
> void main(String[] args) {
>    EntityManager em = ...;
>
>    JFrame f = em.find(JFrame.class, "main");
>    f.show();
>
>    while(true) {}
> }
>
> and use ORM parametrization and "magic" to map S (accounting database
> schema) and C (UI classes) to have accounting UI without pain :)
> (Yes - I know the above is taking ORM to the extreme - but it is _just_ to
> illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas to
> _arbitrary_ class models).
>
> What supporters of JPA say instead is that it is a "good practice" to create
> another class model B (so called "business model") then use ORM to "map" the
> database schema to class model B and then write more code to "map" class
> model B to class model C. The problem is that there is no application
> specific "business logic" I could put into B since all of it is already
> implemented in C.
>
> There is even more "insanity" - once we have class model B - we start using
> data binding library based on reflection (Java Beans conventions) to move
> data from instances of B to instances of C - loosing the last inteded
> benefits of having B (namely type safety).
>
> [snip]
>>
>> Using JDBC on a per-project basis is designing an ORM tool for one
>> particular
>> database schema.  That tool is your data-access layer for that project.
>
> As soon as I get an ORM tool capable of mapping to _arbitrary_ class model I
> am going to use it wholeheartedly. Until that happens I think I would just
> stick to more lightweight tools such as Spring JDBC that resolves some
> inconvinience of JDBC (connection/resource management etc.) while still
> giving me freedom with designing my class model.
>

Well, this is more or less my take on the subject. I rarely go to the 
trouble of explaining it in this length since, as you said, most people 
tend to think we have it all backwards...

On 11-03-28 07:22 PM, Lawrence D'Oliveiro wrote:
> In message <7rudncLSMpvB0A3QnZ2dnUVZ876dnZ2d@telenor.com>, Leif Roar 
> Moldskred wrote:
> 
>> Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>>>
>>> What an odd thing to say. The whole point about relational databases is
>>> that their structure is supposed to reflect the innate logical structure
>>> of the data you’re dealing with—the actual semantics of your business
>>> app.
>>
>> No, the main point of relational databases is to store, change and search
>> large amounts of data in a way that both protects the integrity of the
>> data and has good performance.
> 
> But that “integrity” is part of the semantics of the data.
> 
>> A good match between the business semantics and the relational data-model
>> is certainly a good way to protect the developers' sanity (such as it is)
>> but that's not the purpose or intent of a relational database. Database
>> normalisation will often serve to move the data-model _away_ from the
>> semantic model, and relational DB concepts such as cursors, row locks,
>> foreign keys and joins are downright alien to the semantic model.
> 
> On the contrary: normalization, foreign keys and joins are part of the 
> mathematical formalism that is specifically designed to express that 
> semantics.

I agree, partly. IDEF1 (IDEF1X), for example, is a _semantic_ data
model, and it makes use of primary and foreign keys, and a variety of
relationships. It's entirely semantic to say that one instance of entity
A has a relationship to N instances of entity B, and that a certain set
of attributes of B matches the primary keys of certain instances of A
(foreign key); it becomes a relational database model when we express
that particular relation (and all others in the model) as a set of
n-tuples. However, if I've set up an IDEF1 semantic data model I don't
have to proceed to using a relational model, and although it may not
seem intuitive a relational model is not even a "natural" one to
gravitate towards; it's just the one that gets picked a lot.

Normalization is something else - that's not semantics. It's a technique
for taking a relational database model and turning it into something
practical for use inside an RDBMS. At an even more detailed levels,
cursors and row locks _are_ in fact relational *DB* concepts, not
relational concepts, which distinction was made by Leif.

As for data integrity, that's another topic. I've seen beautiful
3NF/BCNF schemas loaded with extra constraints that still had no data
integrity, because the client application code was defective and was
loading up the tables with crap. Do you have data integrity if 217 table
rows in 5 different tables have perfect consistency in the relational
sense, but 44 of those rows are garbage data in the real world? In fact,
a finely-tuned RDBMS will help you maintain your relationships as you
insert or update or delete that garbage. :-)

AHS
-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

On Mar 29, 9:14=A0am, Silvio <sil...@moc.com> wrote:
> On 03/28/2011 04:53 PM, Michal Kleczek wrote:
>
>
>
>
>
> [snip]
>
> > (BE WARNED: below you're going to find controversial ideas described by=
 a
> > lot of people as "bad engineering practices" - but please read the whol=
e
> > thing before criticizing :) )
>
> > Imagine you have two models: a database schema S and a class library C.=
 Both
> > are completely independent and both capture a certain aspect of the sys=
tem
> > under design.
> > I would consider ORM useful if it helps me to "map" one to another to c=
reate
> > an application that meets some set of requirements. To be precise "mapp=
ing"
> > means moving data from the db to instances of classes from library C
> > (potentially creating instances of those classes) and back to save the =
state
> > of those instances in the database.
>
> > Now imagine schema S desribes an accounting database and library C - cl=
asses
> > implementing neural network computations. There is no single class rela=
ted
> > to accounting in the library C. The only connection between accounting =
and
> > neural networks is the application under design - it provides the neces=
sary
> > context. The question: does it make sense to use ORM to do the "mapping=
"?
>
> > Then imagine library C is a GUI widget library. Does it make sense to u=
se
> > ORM in this case? It would be sooo convinient to be able to write:
>
> > void main(String[] args) {
> > =A0 =A0EntityManager em =3D ...;
>
> > =A0 =A0JFrame f =3D em.find(JFrame.class, "main");
> > =A0 =A0f.show();
>
> > =A0 =A0while(true) {}
> > }
>
> > and use ORM parametrization and "magic" to map S (accounting database
> > schema) and C (UI classes) to have accounting UI without pain :)
> > (Yes - I know the above is taking ORM to the extreme - but it is _just_=
 to
> > illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas=
 to
> > _arbitrary_ class models).
>
> > What supporters of JPA say instead is that it is a "good practice" to c=
reate
> > another class model B (so called "business model") then use ORM to "map=
" the
> > database schema to class model B and then write more code to "map" clas=
s
> > model B to class model C. The problem is that there is no application
> > specific "business logic" I could put into B since all of it is already
> > implemented in C.
>
> > There is even more "insanity" - once we have class model B - we start u=
sing
> > data binding library based on reflection (Java Beans conventions) to mo=
ve
> > data from instances of B to instances of C - loosing the last inteded
> > benefits of having B (namely type safety).
>
> > [snip]
>
> >> Using JDBC on a per-project basis is designing an ORM tool for one
> >> particular
> >> database schema. =A0That tool is your data-access layer for that proje=
ct.
>
> > As soon as I get an ORM tool capable of mapping to _arbitrary_ class mo=
del I
> > am going to use it wholeheartedly. Until that happens I think I would j=
ust
> > stick to more lightweight tools such as Spring JDBC that resolves some
> > inconvinience of JDBC (connection/resource management etc.) while still
> > giving me freedom with designing my class model.
>
> Well, this is more or less my take on the subject. I rarely go to the
> trouble of explaining it in this length since, as you said, most people
> tend to think we have it all backwards...

I think you're both missing a key point: OR mapping is not done just
for the sake of mapping - to bring data straight from the DB to the
GUI and vice-versa. Were it true, then I'd agree that ORMs do not add
any value.
Instead, ORMs exist because most people find it useful to represent
the domain model as "something" which is neither the DB, nor the GUI.
I'm not advocating OO as The Only True Way, but if one chooses Java
(and thus OO), that's basically the main way. So the objective of the
OO programmer is: let's reason about the domain using a class-based
model. Such a model is "pure", it exists in isolation, it is a library
with no interaction with the outside world - at least, it should be.
The OO domain model is the core of the application. While the GUI is
replaceable, the DB is replaceable, etc. the domain model is not - if
you replace it (with a sufficiently different one), you get a
different application. Then, given that everything gravitates around
the domain model, you need every other piece of the application to
talk to it. For GUIs, this means data binding (and a service layer for
client-side GUIs with a server counterpart). For RDBMSes, this means
ORM. For XML, this means JAXB or other mapping technologies, etc. etc.

If you skip the domain model part, and pretend the GUI is the model of
your application, then you're simply not doing Object-Oriented
Programming. That is not a crime, mind you, but then I don't
understand why you're using Java in the first place.

Alessio

Alessio Stalla wrote:

> On Mar 29, 9:14 am, Silvio <sil...@moc.com> wrote:
>> On 03/28/2011 04:53 PM, Michal Kleczek wrote:
>> > As soon as I get an ORM tool capable of mapping to _arbitrary_ class
>> > model I am going to use it wholeheartedly. Until that happens I think I
>> > would just stick to more lightweight tools such as Spring JDBC that
>> > resolves some inconvinience of JDBC (connection/resource management
>> > etc.) while still giving me freedom with designing my class model.
>>
>> Well, this is more or less my take on the subject. I rarely go to the
>> trouble of explaining it in this length since, as you said, most people
>> tend to think we have it all backwards...
> 
> I think you're both missing a key point: OR mapping is not done just
> for the sake of mapping - to bring data straight from the DB to the
> GUI and vice-versa. Were it true, then I'd agree that ORMs do not add
> any value.
> Instead, ORMs exist because most people find it useful to represent
> the domain model as "something" which is neither the DB, nor the GUI.
> I'm not advocating OO as The Only True Way, but if one chooses Java
> (and thus OO), that's basically the main way. So the objective of the
> OO programmer is: let's reason about the domain using a class-based
> model. Such a model is "pure", it exists in isolation, it is a library
> with no interaction with the outside world - at least, it should be.
> The OO domain model is the core of the application. While the GUI is
> replaceable, the DB is replaceable, etc. the domain model is not - if
> you replace it (with a sufficiently different one), you get a
> different application. Then, given that everything gravitates around
> the domain model, you need every other piece of the application to
> talk to it. For GUIs, this means data binding (and a service layer for
> client-side GUIs with a server counterpart). For RDBMSes, this means
> ORM. For XML, this means JAXB or other mapping technologies, etc. etc.
> 

That is a view that I shared for quite some time. But I stopped shortly 
after I became a happy owner of my own programming business and I REALLY had 
to start counting time (hence money) spent on development and maintanance of 
software artifacts.

I think there are several flaws in the approach you suggest and I'll try to 
list them:

1. In reality there is no "one true domain model" - each application (or 
part of the application) has not only _its own_ view of the problem domain 
but actually has _its own_ notion of what the problem domain is.
And this is a primary way of _decoupling_ - this is why we can create 
reusable components. Otherwise we would not be able to create a GUI library 
that is independent of any other class library. We would not be able to 
create a servlet container without coupling it to so called "business domain 
class model"
You would not want Swing or Tomcat to be coupled to accounting would you?

(Also note that looking at the system as a whole - Swing or Tomcat are 
_part_ of it - not something external).

2. Java as a language is much less convinient to describe certain aspects of 
a system - for example SQL is way better in data management and Mathematica 
language in linear programming. So it is a matter of choosing the right tool 
for the job - split your system into _independent_ problem domains (such as 
GUI, networking, data management and sharing, linear programming, accounting 
etc), develop solutions for each using tools the most apropriate for a 
specific problem domain and then integrate them.
If you find Java apropriate to solve a given problem - fine. But it does not 
mean it is apropriate to solve other problems as well. The same reasoning is 
for different Java class libraries solving different problems.

3. Specifically - it is much cheaper to force various applications (or parts 
of a single application) to share a single view of data that is described as 
a database schema than it is to force them to share the same view of data 
using a Java class library ("so called" domain model). It is like this for 
various reasons - one of the most important is - there is much more tools to 
integrate various languages/environments with a RDBMS than to integrate them 
with Java. You don't want to develop those tools by hand.

4. There is no way you can create a class library that is a "rich domain 
model" and is suitable for all aspects of the system - simply because you 
would have to implement all aspects of the system in this library (and you 
don't want to mix GUI and accounting in the same library, do you). Once you 
start removing business logic from it you will end up with an "anemic domain 
model" that in the end is not useful at all.


> If you skip the domain model part, and pretend the GUI is the model of
> your application, then you're simply not doing Object-Oriented
> Programming. 

Of course I am. I'm just choosing different abstractions (the most suitable 
to solve the problem in hand). How is GUI less OO than accounting logic?

> That is not a crime, mind you, but then I don't
> understand why you're using Java in the first place.

See above. I'm using Java where it makes sense.

-- 
Michal

Silvio wrote:

> 
> Well, this is more or less my take on the subject. I rarely go to the
> trouble of explaining it in this length since, as you said, most people
> tend to think we have it all backwards...

Sometimes whan I am sad I think of:
http://en.wikipedia.org/wiki/Galileo_Galilei
:)

-- 
Michal

On 03/29/2011 12:49 PM, Michal Kleczek wrote:

> That is a view that I shared for quite some time. But I stopped shortly
> after I became a happy owner of my own programming business and I REALLY had
> to start counting time (hence money) spent on development and maintanance of
> software artifacts.
>

That may be it. I have been in the same position for over 15 years now. 
Perhaps that is why we look at this a bit differently.

On 03/29/2011 12:06 PM, Alessio Stalla wrote:
[snip]

> If you skip the domain model part, and pretend the GUI is the model of
> your application, then you're simply not doing Object-Oriented
> Programming. That is not a crime, mind you, but then I don't
> understand why you're using Java in the first place.
>
> Alessio

I could not disagree more. There is no "one ultimate OO way" of doing 
things. Nor is it clear cut whether any program fragment is "OO" or not. 
Neither does OO mean you have to have an object model that is separate 
from the UI (or any other part of the system). Why would coupling an 
object model to the UI be any worse than coupling it to the database? In 
most cases I would strive to decouple it from both.

OO is a programming methodology, just like functional programming and 
even procedural programming. Neither methodology prescribes a single 
solution for any problem.


And I am not using Java (which I consider only a weakly Object Oriented 
language). I program in Scala but I am using the JVM and my share of 
Java libraries.

Michal Kleczek wrote:
> Silvio wrote:
>> Well, this is more or less my take on the subject. I rarely go to the
>> trouble of explaining it in this length since, as you said, most people
>> tend to think we have it all backwards...
>
> Sometimes whan I am sad I think of:
> http://en.wikipedia.org/wiki/Galileo_Galilei
> :)

Sometimes when I am sad I think of kittens and butterflies.

-- 
Lew
Kittens enjoy playing with butterflies.  Then eating them.

In message <TVhkp.2110$sS4.2012@newsfe11.iad>, Arved Sandstrom wrote:

> Normalization is something else - that's not semantics. It's a technique
> for taking a relational database model and turning it into something
> practical for use inside an RDBMS.

No it is not. It is integral to the mathematical concept of relations.

In message <imsffl$18s$1@news.onet.pl>, Michal Kleczek wrote:

> Sometimes whan I am sad I think of:
> http://en.wikipedia.org/wiki/Galileo_Galilei
> :)

Could be worse <http://en.wikipedia.org/wiki/Giordano_Bruno> ...

In message 
<8189bddb-1e17-428a-96ca-4c0ae5dabacc@d19g2000yql.googlegroups.com>, Alessio 
Stalla wrote:

> Instead, ORMs exist because most people find it useful to represent
> the domain model as "something" which is neither the DB, nor the GUI.

I would describe that as the “business logic API”, insofar as parts of it 
need to be common across multiple applications.

Fair enough that parts of that cannot be expressed merely as database 
constraints, but I would not like to see it tied to a GUI.

On 11-03-30 09:19 PM, Lawrence D'Oliveiro wrote:
> In message <TVhkp.2110$sS4.2012@newsfe11.iad>, Arved Sandstrom wrote:
> 
>> Normalization is something else - that's not semantics. It's a technique
>> for taking a relational database model and turning it into something
>> practical for use inside an RDBMS.
> 
> No it is not. It is integral to the mathematical concept of relations.
> 
Lawrence, normalization is basically a set of design techniques
associated with the relational data model, and the relational data model
is a _logical_ data model, not a conceptual one that defines the
semantics. So how is normalization integral to semantics again?

And by the way, if you can't define a relation without using the term
"normalization" then you're missing the point. And don't confuse a
modern relational database with the relational model.

AHS

-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

In message <IX7lp.805$YL5.263@newsfe05.iad>, Arved Sandstrom wrote:

> On 11-03-30 09:19 PM, Lawrence D'Oliveiro wrote:
>
>> In message <TVhkp.2110$sS4.2012@newsfe11.iad>, Arved Sandstrom wrote:
>> 
>>> Normalization is something else - that's not semantics. It's a technique
>>> for taking a relational database model and turning it into something
>>> practical for use inside an RDBMS.
>> 
>> No it is not. It is integral to the mathematical concept of relations.
>> 
> Lawrence, normalization is basically a set of design techniques
> associated with the relational data model, and the relational data model
> is a _logical_ data model, not a conceptual one that defines the
> semantics.

Difference being?

> And by the way, if you can't define a relation without using the term
> "normalization" then you're missing the point.

Maybe you’ve been befogged by SQL, to the point where you don’t notice the 
mathematics underneath.

On Thu, 31 Mar 2011, Arved Sandstrom wrote:

> the relational data model is a _logical_ data model, not a conceptual 
> one that defines the semantics.

What's the difference between a logical model and a conceptual model?

tom

-- 
FREQUENT VIOLENT BLOODY

On 11-04-01 06:38 PM, Tom Anderson wrote:
> On Thu, 31 Mar 2011, Arved Sandstrom wrote:
> 
>> the relational data model is a _logical_ data model, not a conceptual
>> one that defines the semantics.
> 
> What's the difference between a logical model and a conceptual model?
> 
> tom
> 
Let's put it this way - I doubt you'll find an authoritative reference
that informs us exactly what is a conceptual data model, exactly what is
a logical data model, and exactly what is a physical data model. However
the terminology, and that division into three levels of abstraction of
data modeling, is quite common.

A conceptual model equates to a business model. You might have entities
for Person, Address, and LifeEvent, say. There is just enough
information in the description of each to support a _business-level_
discussion of relationships and identifying information and extra
information.

It's in the logical model that, assuming we are talking about a
relational logical data model, that we might say that Person has
person_id as a primary key, that there's a M:N between Person and
Address and we describe the join table, there's a 1:N between Person and
LifeEvent, we specify exactly what the tables are and what columns
exist, what columns are foreign keys, and so forth.

In a physical model not only do I already know that I'm using an RDBMS,
I know I'm using Oracle or SQL Server. I'm writing the details of my JPA
and deciding what my indexes are, and what the syntax is for a boolean
data type.

In the conceptual model there's no such thing as tables or columns, and
we're not overly worried about datatypes or about exactly how we are
going to define the primary key for Person. You should be able to take
your conceptual model and be able to choose something other than a
relational model as your logical data model, is the point.

AHS
-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

On 11-03-31 09:10 PM, Lawrence D'Oliveiro wrote:
> In message <IX7lp.805$YL5.263@newsfe05.iad>, Arved Sandstrom wrote:
> 
>> On 11-03-30 09:19 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message <TVhkp.2110$sS4.2012@newsfe11.iad>, Arved Sandstrom wrote:
>>>
>>>> Normalization is something else - that's not semantics. It's a technique
>>>> for taking a relational database model and turning it into something
>>>> practical for use inside an RDBMS.
>>>
>>> No it is not. It is integral to the mathematical concept of relations.
>>>
>> Lawrence, normalization is basically a set of design techniques
>> associated with the relational data model, and the relational data model
>> is a _logical_ data model, not a conceptual one that defines the
>> semantics.
> 
> Difference being?

See my explanation to Tom.

>> And by the way, if you can't define a relation without using the term
>> "normalization" then you're missing the point.
> 
> Maybe you’ve been befogged by SQL, to the point where you don’t notice the 
> mathematics underneath.

I'm reasonably familiar with the mathematics of tuples and relations. I
also know that when I'm using a typical RDBMS and SQL that I'm not
constrained to a relational representation of my data.

AHS
-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

In message <LQslp.6717$sS4.1488@newsfe11.iad>, Arved Sandstrom wrote:

> A conceptual model equates to a business model. You might have entities
> for Person, Address, and LifeEvent, say. There is just enough
> information in the description of each to support a _business-level_
> discussion of relationships and identifying information and extra
> information.
> 
> It's in the logical model that, assuming we are talking about a
> relational logical data model, that we might say that Person has
> person_id as a primary key, that there's a M:N between Person and
> Address and we describe the join table, there's a 1:N between Person and
> LifeEvent, we specify exactly what the tables are and what columns
> exist, what columns are foreign keys, and so forth.

I still don’t see how you separate between “conceptual” and “logical”. One 
flows from the other; there is no boundary between them.

In message <gZslp.3268$0s5.1254@newsfe17.iad>, Arved Sandstrom wrote:

> On 11-03-31 09:10 PM, Lawrence D'Oliveiro wrote:
>
>> In message <IX7lp.805$YL5.263@newsfe05.iad>, Arved Sandstrom wrote:
>> 
>>> And by the way, if you can't define a relation without using the term
>>> "normalization" then you're missing the point.
>> 
>> Maybe you’ve been befogged by SQL, to the point where you don’t notice
>> the mathematics underneath.
> 
> I'm reasonably familiar with the mathematics of tuples and relations. I
> also know that when I'm using a typical RDBMS and SQL that I'm not
> constrained to a relational representation of my data.

How else do you express relationships?

On 11-04-01 11:45 PM, Lawrence D'Oliveiro wrote:
> In message <gZslp.3268$0s5.1254@newsfe17.iad>, Arved Sandstrom wrote:
> 
>> On 11-03-31 09:10 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message <IX7lp.805$YL5.263@newsfe05.iad>, Arved Sandstrom wrote:
>>>
>>>> And by the way, if you can't define a relation without using the term
>>>> "normalization" then you're missing the point.
>>>
>>> Maybe you’ve been befogged by SQL, to the point where you don’t notice
>>> the mathematics underneath.
>>
>> I'm reasonably familiar with the mathematics of tuples and relations. I
>> also know that when I'm using a typical RDBMS and SQL that I'm not
>> constrained to a relational representation of my data.
> 
> How else do you express relationships?

That's not exactly what I was getting at, relationships, although I'll
touch on that. Assuming however that I am using a relational model for
my data (e.g. I have relation Person, relation Address, and relation
LifeEvent, say), the 1:N relationship that I have between relation
Person and relation LifeEvent I can describe by having a foreign key
column in LifeEvent, the domain of which is the primary keys of Person;
obviously a query that exploits that relationship also returns relations.

This is all relationships in a relational data model, though. If I am
not even using relations to describe my entities, why would you expect
relationships to be described in a relational manner?

Back to my original point: common RDBMSs aren't completely relational.
We can have duplicate rows in tables (this includes relations returned
by queries), and you can't have duplicate tuples in relations. This
whole business with DISTINCT is a patch...and can also be a code smell
since it may be hiding errors. Also, NULL isn't quite kosher - it's an
SQL afterthought. In that relationship I concocted above, I can have a
foreign key, potentially, on a row of LifeEvent which is NULL...that is,
it points to no Person. I can constrain that foreign key to be NOT NULL
but I shouldn't be allowed to make values NULL in the first place. The
use of NULLs in general mean that you've got poorly structured data.
Coupled with what you can do with SQL it can/will often lead to yet more
errors.

AHS
-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

On 11-04-01 11:44 PM, Lawrence D'Oliveiro wrote:
> In message <LQslp.6717$sS4.1488@newsfe11.iad>, Arved Sandstrom wrote:
> 
>> A conceptual model equates to a business model. You might have entities
>> for Person, Address, and LifeEvent, say. There is just enough
>> information in the description of each to support a _business-level_
>> discussion of relationships and identifying information and extra
>> information.
>>
>> It's in the logical model that, assuming we are talking about a
>> relational logical data model, that we might say that Person has
>> person_id as a primary key, that there's a M:N between Person and
>> Address and we describe the join table, there's a 1:N between Person and
>> LifeEvent, we specify exactly what the tables are and what columns
>> exist, what columns are foreign keys, and so forth.
> 
> I still don’t see how you separate between “conceptual” and “logical”. One 
> flows from the other; there is no boundary between them.

There is no super-distinct boundary, no. But there is a boundary
nonetheless. In the conceptual (semantic) model when we are thinking
about Person, we'll have a notion of Person identity - what attributes
of Person make them unique - but at this level that uniqueness could be
opaquely described as PersonID of no particular datatype, and we then go
on to discuss other attributes of Person that are necessary for the
business problem. Similarly, when thinking at this conceptual level
about LifeEvent, we might simply say that each LifeEvent instance will
point at a Person using the PersonId value.

At this stage of the game nobody is talking about tables and rows
(relations and tuples), and if we decide to not use a relational model
we don't have to.

Part of the real-world problem is that in the majority of projects
people already _assume_ relational. So all of their
business/conceptual/semantic work is intertwined with implementation
details.

AHS
-- 
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

Arved Sandstrom wrote:
> There is no super-distinct boundary, no. But there is a boundary
> nonetheless. In the conceptual (semantic) model when we are thinking
> about Person, we'll have a notion of Person identity - what attributes
> of Person make them unique - but at this level that uniqueness could be
> opaquely described as PersonID of no particular datatype, and we then go
> on to discuss other attributes of Person that are necessary for the
> business problem. Similarly, when thinking at this conceptual level
> about LifeEvent, we might simply say that each LifeEvent instance will
> point at a Person using the PersonId value.

To this excellent taxonomy I would add only that the conceptual "PersonID" 
would identify the natural, or innate identifying data, one might say the 
"primary key".  That's not correct at this level, though - what we're aiming 
for are the attributes that determine entity identity within the semantic model.

A surrogate key, such as an integer-valued ID that perhaps is from a sequence, 
is something introduced in the physical model.

-- 
Lew