Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 10, 2008 Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to dolive | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to dolive | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Kyllingstad | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Kyllingstad | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to dolive | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Aarti_pl | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to dolive | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Aarti_pl | 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 Re: Some people to convert jdo2.2 to d ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Aarti_pl | 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.
|
Copyright © 1999-2021 by the D Language Foundation