On Sun, Feb 3, 2013 at 4:21 PM, Mateusz Loskot <[email protected]> wrote:
> Aleksander, Vadim,
>
> Well caught points!
>
>
> On 3 February 2013 22:35, Vadim Zeitlin <[email protected]> wrote:
> > On Sun, 3 Feb 2013 14:31:06 -0800 Pawel Aleksander Fedorynski <
> [email protected]> wrote:
> > PAF> On Sun, Feb 3, 2013 at 2:26 PM, Vadim Zeitlin <[email protected]>
> wrote:
> > PAF> > On Sun, 3 Feb 2013 14:17:49 -0800 Pawel Aleksander Fedorynski <
> > PAF> > [email protected]> wrote:
> > PAF> >
> > PAF> > PAF> It occurs to me that some other db engines (Oracle?)
> probably send
> > PAF> > values
> > PAF> > PAF> in non-string format, what should into_as_raw_text() do then?
> > PAF> > PAF>
> > PAF> > PAF> (a) signal an error?
> > PAF> > PAF>
> > PAF> > PAF> (b) put the raw value (which may be non-printable and may be
> packed
> > PAF> > in some
> > PAF> > PAF> unobvious way) in the provided string, say the value is of
> type INT32
> > PAF> > and
> > PAF> > PAF> some db sends four bytes over the wire, should we put these
> exact four
> > PAF> > PAF> bytes into the string?
> > PAF> > PAF>
> > PAF> > PAF> (c) convert to string?
> > PAF> >
> > PAF> > I'd say (b). "Raw" would seem to mean this, i.e. exactly the
> bytes
> > PAF> > received.
> > PAF>
> > PAF> Yes, I was thinking the same thing. But then it shouldn't be
> raw_text,
> > PAF> raw_string maybe or raw_bytes even?
> >
> > Yes, taking this into account, into_raw_bytes() or maybe
> into_raw_buffer()
> > (just because "buffer" is something you can put things into, while
> > "bytes"... not so much IMHO) does seem better, thanks!
>
> One may argue 'raw' is not so meaningful either, so into_bytes_buffer()
> with implicit assumption, bytes is a raw form of data (in software in
> general).
>
> The std::string sink type for into_raw_buffer() might not be the best
> choice
> as it has different semantic. It is a (null-terminated, if [1] is accepted)
> character sequence.
>
std::string is a perfectly valid choice for binary data, it is a sequence
of bytes not of characters. Your reference proposes that there is always
an extra zero-byte stored after all the bytes in the string, which changes
nothing from the point of view of using the string, it would be an
implementation convenience for c_str(). It certainly does not propose that
there are no zero bytes allowed in the middle of the string.
> Wouldn't it be clearer to have into_raw_buffer(std::vector<byte>) ?
>
> The discussion about the into_as_raw_text() and later about
> into_raw_buffer()
> made me think if this idea potentially could share some common
> elements with binary data support.
>
> Here I have a branch
> https://github.com/mloskot/soci/tree/soci-type-binary
> where I've been working on binary data support for SOCI
> https://github.com/mloskot/soci/commit/8f5ea63f
> The prototype is very basic:
> 1) New into/use type indicated by x_binary_string
> 2) Trivial, but SOCI-defined bytes buffer
> namespace soci {
> struct binary_string
> {
> std::vector<std::uint8_t> data_;
> };
> }
>
I see no upside to introducing any such type. std::string is perfectly
sufficient from the practical point of view and is more convenient, not to
mention standardized. And if any SOCI user wants a special type for
whatever reason, chances are they will have their own custom type for
storing binary strings and will convert or type-cast from your
soci::binary_string to their own type, so they might as well convert from
std::string.
Best,
Aleksander
3) The data exchange machinery updated to recognise the new x_binary_string
>
> It seems to be, that the into_raw_buffer() and the binary support
> require the same kind of data type - a container for sequence of bytes
> of arbitrary length - a buffer.
>
> Would it be possible to have single container for raw byte sequence in
> SOCI?
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
