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