[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