Db access design - call for comments (& help)

[Marcin Kuszczak]

Lars Ivar Igesund wrote:

> Marcin Kuszczak wrote:.
> 
>> If you or someone else wanted to help in such a framework (I will use
>> probably BSD license) I will put code somewhere, so it will be possible
>> to work on it together. In such a case please drop me an email. First
>> thing to do is to rethink architecture and found even better ways of
>> doing things... :-)
> 
> Since I am working on DDBI, I was curious as to whether you are competing,
> or building something that would/could live on top of it :)
> 

I would say that to make full usage of my framework people should drop using SQL's as strings. I am unconvinced that all people will do that, even if using string SQLs is very error prone. So in this area it will be just a layer on top of DDBI.
In this area DDBI could provide interface to send data directly to databases as structs of data, by-stepping SQL parsing.  That would probably make using SQL objects faster than normal queries. Although I don't know if such a possibility is implemented in any database. :-]

The second area is returning data from queries. In this area it can be done much more to allow seamless integration with higher level container used to pass data inside application. I see here two possibilities:

1. DDBI will provide only very thin layer over database interface. Probably it should be kind of callback for "fetchRow" from database. It shouldn't be container, as when using my framework it would be necessary to process data and put them into another specific container, so there would be overhead. I use 'variant' as internal representation for containers, and it would desirable to get same 'variant' from DDBI. Optionally it should be just a simple D type.

2. The second option is that DDBI queries will return containers, which are somehow compatible with higher level containers used in my framework, so there will be no overhead when transforming one into the other. But I think that it is rather inferior solution to the first one.

DDBI can also provide some interface to get mapping between D type and database type (D type --> db type string). I need this information to generate SQL string queries before sending them to database. As the other way (database type to D type) must be done anyway in DDBI,  so I think that D type to database type should be also in the same layer.

Also getting metadata for queries in DDBI should not be "included by default" with getting normal data. In my framework I don't have to rely  on metadata from database *at all* as all metadata are defined much earlier in program and they are fully known during queries. (So, there must be a way to get data from column by its number and not only by its name).

When above conditions are fulfilled, then my framework will be just a higher layer in D database access. If some of above conditions are not met, there will be additional unnecessary cost when using my framework and functionalities will cross, so they will compete.

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