Re: [boost] SOCI 3.0.0 - The Database Access Library

From: Maciej Sobczak (prog_at_[hidden])
Date: 2008-07-11 09:43:35

Phil Endecott wrote:

> When necessary, the approach that I've taken is for the client to define 
> the expected data type, but to do this using a cast inside the SQL string:
> 
> "select salary::int64 from ..."
> 
> You can then be fairly certain that you'll actually get a 64-bit value 
> back.

> Then at execution time, all I do is a quick check that the retuned 
> column types are the expected ones, and throw if they aren't.

This is a big burden on the user and is very fragile.
Consider:

typedef int SalaryType;
// ...

SalaryType salary;
sql << "select salary from ...", into(salary);

Not only it is not clear at the use point what type should be put in the 
textual query, but whatever you put there will fail just a few months 
later when you upgrade the source code and change the typedef in the one 
place where it is defined. Facilitating such changes is one of the 
purposes of typedef, after all.

Note also that the above solution is impractical if queries are not 
encoded in source code, but exist externally, for example in resource 
files (or even in a database). The same query might be reused in many 
places, even if the target data type might be different.

Note also that calling stored procedures is tricky/impractical with this 
approach, because result types are encoded in the signature or 
definition of the procedure and are not normally exposed in the query 
that calls it.

Regards,

-- 
Maciej Sobczak * www.msobczak.com * www.inspirel.com