[GSOC] Database API draft proposal

Fawzi Mohamed fawzi at gmx.ch
Sun Apr 3 10:16:59 PDT 2011


On 3-apr-11, at 18:37, Piotr Szturmaj wrote:

> Fawzi Mohamed wrote:
>> I think that you project looks nice, but see some of the comments  
>> in my
>> other message.
>> I would for example consider separating table definition from row
>> object, and while your row object is really nice, often one has  
>> either a
>> single DB model, described in a few model files or goes with a fully
>> dynamic model.
>> In large project one does not/should not, define RowTypes on the fly
>> everywhere in the code.
>
> There's no need to declare all row types. DBRow support both static  
> and dynamic models. For dynamic rows, DBRow uses Variant[] as its  
> underlying type. This is previous sample code, but changed to use  
> dynamic row:
>
> auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
> auto result = cmd.executeQuery;
>
> foreach (row; result)
> {
>    // here, row subtypes a Variant[]
>    writeln(row[0], ", ", row[1]);
> }
>
> Btw. I've just updated documentation, so you can take another look :)

Yes I saw that, that is exactly the reason I was telling about  
splitting the table definition in another object, so that also in the  
dynamic case one can use the column names (that normally are known, or  
can be retrieved from the db schema).
That would only add a pointer to each row (to its description), and  
would make it much nicer to use.
Your DBRow is very nice to use, and I like how it can accommodate both  
types, but it degrades too much for dynamic types imho.

Fawzi



More information about the Digitalmars-d mailing list