Some people to convert jdo2.2 to d ?

[Marcin Kuszczak]

Christopher Wright wrote:

> Aarti_pl wrote:
>> ...and this high-level design is IMHO mistake. Especially mapping
>> relations from db to objects.
>> 
>> Well maybe someone will give me examples where domain objects are more
>> useful than relations? From my observations presentation layer (GUI) is
>> also relational, so I don't see a sense with making conversions:
>> relation -> object -> relation.
>> 
>> I am working on db access framework which makes use of relations rather
>> than creating objects. And it makes it in typesafe way...
>> 
>> BR
>> Marcin Kuszczak
>> (aarti_pl)
> 
> It's fine if you're just doing CRUD operations. At my job, we do staff
> scheduling software -- I'd kill myself if I had to write the scheduling
> engine or rule violation code in terms of database rows. And that would
> be a major performance issue.

Well, really I don't get what the problem is here. Could you please elaborate more?

> A good ORM solution will help prevent data inconsistency issues. Let's
> say you need this superfast query in one area but it returns some data
> that you already have. If you manipulated that data in memory already
> and haven't committed it to the database already (because database
> access is slow, so you don't want to be committing everything all the
> time), your application will be in an inconsistent state.

Yes, probably there are ORM solutions which keeps data consistent . But please notice that "keeping data consistent" is not a property of ORM itself. It's just that people implemented something like that in ORM systems. I am sure that it is possible to make data consistency layer also in relational system. I just don't want object Person in my program, but instead just row with person's data.

> Also, touching the database is slow. It requires inter-process
> communication; it requires translating data from the database's internal
> format to whichever format it sends over the wire; it requires
> translating from that intermediate format to something the application
> can handle.

Sure. But mapping this resulting format into objects is even slower. That's in fact one of major arguments against ORM.

> If you can do your query in memory, that's often going to be
> faster. 

Again. Queries in memory is not a property of ORM. In fact you make them always when you iterate specific collection e.g. searching for specific value.

> There are exceptions, such as when your database schema is
> significantly different than your objects (in which case this isn't very
> good object-relational mapping), or when the query returns very few rows
> and you have a huge amount of objects in memory, or when the database is
> indexed on rows and you don't replicate that in your application.
> 
> And doing in-memory queries isn't possible unless you have a collection
> of objects that is a guaranteed superset of the desired output.

As I said above - please notice that you can make queries in memory also in relational model. In fact I implemented it in my db access framework in quite universal way as 'agents'.

> In general I prefer ORM. At the very least to translate rows into
> objects, and to write basic CRUD queries for me; that keeps my database
> access layer up to date.
> 
> Also, it's a lot faster to write code with ORM than it is to write
> custom SQL. I've heard people saying that if you are writing a custom
> database layer in SQL, you're stealing from your employer. This
> presumes, of course, that you're working in a language with a suitable
> ORM library available.

Well I think that it is just because that there was a lot of man-power putted into ORM frameworks. And that was probably just because of philosophical reasons - not pragmatical. :-)

Please see also my other post about my Db access framework. 

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------