[GSOC] Database API draft proposal

[Piotr Szturmaj]

Fawzi Mohamed wrote:
>
> 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.

Ah, I see what you mean :) This is yet to be done feature :)

I assume you mean something like row["typname"]. Soon, I will add 
support for this.