[GSOC] Database API draft proposal

[Fawzi Mohamed]

On 3-apr-11, at 19:54, Piotr Szturmaj wrote:

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

yes exactly, great