Re: [boost] SOCI 2.2.0 - The C++ Database Access Library

From: Martin Adrian (adrianm_at_[hidden])
Date: 2006-12-06 10:21:52

Maciej Sobczak <prog <at> msobczak.com> writes:

Thank you for your quick reply.

> There is also a third option here, probably most generic - expose the 
> whole stream object, so that users can play with it on their own; this 
> goes far beyond locale control, you can even replace the whole streambuf 
> there. I don't see any immediate use for this, but we didn't foresee the 
> locale issue either.

Still think it would better if the backend decides how numbers, dates etc
should be formatted in the sql string.

> 
> > why not have a "intonull" expression that take a second nullValue
> > argument:
> > sql << "select a,b,c,d... from tbl", intonull(vara, ""), intonull(
> > varb, -1)...

> First note: you don't have to create indicator vars if you don't expect 
> nulls.
> Second, the above assumes that you have some default value to replace 
> the null. Isn't there a dedicated SQL function for this?

I often run into databases where string fields can both be empty and null
with no difference in meaning (just bad design).

COALESCE is possible but I think the null handling should be in the code
not in the sql statement. What I'm asking for is just some syntactic sugar.

> What about:
> 
> sql << "select ...", into(a, default("")), into(b, default(-1));
> 
> The point is that there is already a framework for extending into 
> elements this way.

Yes that would be ok. (default is a reserved word but I understand
what you mean).

> > sql << "select x from tbl", into(a);
> > if (!sql.empty())
> >   // something was fetched
> > 
> > or
> > sql << "update tbl set x = 2 where y = 3";
> > if (sql.rowsaffected() == 0)
> >   // not found
> 
> Yes, that's one possible approach. Boost.optional would handle the
> rest. We have to review this subject.

Another approach could be to follow the stream syntax with eof()
and bad().