Jump to page: 1 2
Thread overview
Some people to convert jdo2.2 to d ?
Nov 10, 2008
dolive
Nov 12, 2008
dolive
Nov 12, 2008
Lars Kyllingstad
Nov 12, 2008
Kagamin
Nov 12, 2008
dolive
Nov 12, 2008
Aarti_pl
Nov 12, 2008
Ary Borenszweig
Nov 13, 2008
Marcin Kuszczak
Nov 12, 2008
Christopher Wright
Nov 13, 2008
Marcin Kuszczak
Nov 14, 2008
Christopher Wright
Nov 16, 2008
Marcin Kuszczak
Nov 16, 2008
Christopher Wright
Nov 12, 2008
Lars Ivar Igesund
November 10, 2008
Some people to convert jdo2.2 for rdbms to d ?

http://www.datanucleus.org/ http://www.datanucleus.org/products/accessplatform_1_1/index.html
November 12, 2008
dolive дµ½:

> Some people to convert jdo2.2 for rdbms to d ?
> 
> http://www.datanucleus.org/ http://www.datanucleus.org/products/accessplatform_1_1/index.html

Nobody wants to do?

d language very powerful, but unfortunately, at present is missing a good database project¡£
November 12, 2008
dolive wrote:
> dolive дµ½:
> 
>> Some people to convert jdo2.2 for rdbms to d ?
>>
>> http://www.datanucleus.org/
>> http://www.datanucleus.org/products/accessplatform_1_1/index.html
> 
> Nobody wants to do?
> 
> d language very powerful, but unfortunately, at present is missing a good database project¡£

There is DDBI, but I don't know if this is what you are looking for.

http://www.dsource.org/projects/ddbi

-Lars
November 12, 2008
Lars Kyllingstad Wrote:

> There is DDBI, but I don't know if this is what you are looking for.
> 
> http://www.dsource.org/projects/ddbi
> 
> -Lars

As I can see, data nucleus is more high-level like Hibernate.
November 12, 2008
Lars Kyllingstad дµ½:

> dolive wrote:
> > dolive дµ½:
> > 
> >> Some people to convert jdo2.2 for rdbms to d ?
> >>
> >> http://www.datanucleus.org/ http://www.datanucleus.org/products/accessplatform_1_1/index.html
> > 
> > Nobody wants to do?
> > 
> > d language very powerful, but unfortunately, at present is missing a good database project¡£
> 
> There is DDBI, but I don't know if this is what you are looking for.
> 
> http://www.dsource.org/projects/ddbi
> 
> -Lars



the ddbi progress is too really slow, difficult to look forward to¡£ data nucleus is more high-level like Hibernate.

November 12, 2008
dolive pisze:
> Lars Kyllingstad Đ´ľ˝:
> 
>> dolive wrote:
>>> dolive Đ´ľ˝:
>>>
>>>> Some people to convert jdo2.2 for rdbms to d ?
>>>>
>>>> http://www.datanucleus.org/
>>>> http://www.datanucleus.org/products/accessplatform_1_1/index.html
>>> Nobody wants to do?
>>>
>>> d language very powerful, but unfortunately, at present is missing a good database projectĄŁ
>> There is DDBI, but I don't know if this is what you are looking for.
>>
>> http://www.dsource.org/projects/ddbi
>>
>> -Lars
> 
> 
> 
> the ddbi progress is too really slow, difficult to look forward toĄŁ
> data nucleus is more high-level like Hibernate.
> 

...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)
November 12, 2008
Aarti_pl wrote:
> dolive pisze:
>> Lars Kyllingstad Đ´ľ˝:
>>
>>> dolive wrote:
>>>> dolive Đ´ľ˝:
>>>>
>>>>> Some people to convert jdo2.2 for rdbms to d ?
>>>>>
>>>>> http://www.datanucleus.org/
>>>>> http://www.datanucleus.org/products/accessplatform_1_1/index.html
>>>> Nobody wants to do?
>>>>
>>>> d language very powerful, but unfortunately, at present is missing a good database projectĄŁ
>>> There is DDBI, but I don't know if this is what you are looking for.
>>>
>>> http://www.dsource.org/projects/ddbi
>>>
>>> -Lars
>>
>>
>>
>> the ddbi progress is too really slow, difficult to look forward toĄŁ
>> data nucleus is more high-level like Hibernate.
>>
> 
> ...and this high-level design is IMHO mistake. Especially mapping relations from db to objects.

I must agree with you. That kind of mapping is nice until you realize some specific operation must really be super fast, and the only way to do that is with a custom, super specific query... and then you start breaking all that abstractions, and everything results in a mess. Pure SQL, abstracted by convenient methods, is what I prefer. These methods may return objects that represent entities.
November 12, 2008
dolive wrote:

> Lars Kyllingstad �:
> 
>> dolive wrote:
>> > dolive �:
>> > 
>> >> Some people to convert jdo2.2 for rdbms to d ?
>> >>
>> >> http://www.datanucleus.org/ http://www.datanucleus.org/products/accessplatform_1_1/index.html
>> > 
>> > Nobody wants to do?
>> > 
>> > d language very powerful, but unfortunately, at present is missing a good database project��
>> 
>> There is DDBI, but I don't know if this is what you are looking for.
>> 
>> http://www.dsource.org/projects/ddbi
>> 
>> -Lars
> 
> 
> 
> the ddbi progress is too really slow, difficult to look forward to�� data nucleus is more high-level like Hibernate.

Yes, it has been moving a tad too slow - it should improve somewhat at least, but the scope of DDBI is not really as high level as what you want - at least not from the onset.

Lars Ivar
November 12, 2008
Hello Aarti_pl,

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

Agree. I haven't been satisfied with any ORM I've tryied until now. The best until now has been LINQ to SQL but Microsoft it's killing it.

Can you provide us any details on your project? It sounds a lot like .NET typed datasets.

Thanks


November 12, 2008
Aarti_pl wrote:
> dolive pisze:
>> the ddbi progress is too really slow, difficult to look forward toĄŁ
>> data nucleus is more high-level like Hibernate.
>>
> 
> ...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.

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.

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. If you can do your query in memory, that's often going to be faster. 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.

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.
« First   ‹ Prev
1 2