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
