Some people to convert jdo2.2 to d ?

[dolive]

Christopher Wright дµ½:

> Marcin Kuszczak wrote:
> > 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?
> 
> Scheduling, you assign people to shifts. That's a many-to-many 
> relationship. If I just had database rows, assigning would be a matter 
> of adding a row. With real objects, I have a set of people associated 
> with each shift. This means it's O(1) to check if someone's assigned 
> rather than O(number of assignments).
> 
> There are a lot of things like this. You can use the active record 
> pattern, but that's essentially an implementation detail for ORM.
> 
> >> 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.
> 
> You want a database interaction layer that will return the same row for 
> multiple queries, assuming that the row has the same primary key.
> 
> Joins are an issue with this. You're not updating a row retrieved from a 
> join, but you're getting it from the database, and your in-memory row 
> might be dirty.
> 
> >> 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.
> 
> True, thank you for correcting me.
> 
> There's still one problem with doing queries, even if you ignore 
> database access. How are you going to arrange these rows? If you want to 
> do interesting operations, not just CRUD, will it be sufficiently fast 
> to have arrays or sets of rows? And will this be convenient from a 
> programming point of view? If not, you're left with implementing active 
> record yourself.
> 
> If you are merely doing CRUD operations, a decent ORM might be able to 
> write your queries and database schema for you. If the result is 
> reasonable, you've saved a fair bit of time. If not, you've wasted a 
> small amount of time.
> 
> If you have significant business logic, in my experience, you're better 
> off with ORM.
> 
> >> 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. :-)
> 
> So what you're saying is that a lot of strangers put a lot of effort 
> into ORM, and this means that I don't have to do as much work. I'm happy 
> with that.
> 
> > Please see also my other post about my Db access framework. 
> > 


conversion ado.net + nHibernate to d£¿
 d need a powerful database project