SQL working [ was Re: The sorry state of the D stack? ]

Piotr Szturmaj bncrbme at jadamspam.pl
Sun Oct 7 12:10:37 PDT 2012


Thiez wrote:
> On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:
>> In my prostgres client one may specify field types at compile time. If
>> I had divided the client into two separate layers it would return a
>> Variant[] at first layer, then convert it to user specified tuple at
>> the second. For example:
>>
>> auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
>> auto untypedRow = connection.executeRow(); // return DBRow!(Variant[])
>> auto typedRow = connection.executeRow!(int, string)(); // returns
>> DBRow!(int, string);
>>
>> Internally executeRow could always take a Variant[], then convert it
>> to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate
>> an array of two Variants, then each Variant must be coerced to the
>> corresponding type.
>>
>> Just wanted to illustrate that "layers" shouldn't always be separate.
>
> It's not a very convincing illustration. In practice the overhead of
> those operations would likely be completely insignificant compared to
> performing the actual database query. Avoiding intermediate layers for
> optimality's sake seems like a bad case of premature optimization to me.

In my opinion everything counts. For thousands of rows x thousands of 
clients it certainly _should_ make a difference. And I wouldn't call it 
premature optimization, it's just _designed_ to be fast.


More information about the Digitalmars-d mailing list