Hi,
I have a table that contains a BLB and I'd like to use an SSQLS to
query it.
e.g.
Int
Int
Blob - containing 200 floats in binary format
Varchar(128)
Varchar(128)
I use an sql_create_5() statement to define my table elements and then I
do a query.storein() on the vector created with the structure (which in
turn is created by sql_create_5()). Everything works fine. Both Int and
Varchar fields are correct!
The problem is that - if I understood things correctly - I can only
define a BLB as a std::string. And when I execute my query and try to
access the data in the BLB, it stops after the first hex 00 (which is
"normal" since it's a string). Problem is that even if I access the
data() member of the string, I only get the bytes till the first 00.
So basically my question is: Is it possible to use sql_create_#() with
BLBS or do I have to go the "standard" way (non-SSQLS way that is)?
Hope I'm just missing something obvious and I'll be able to use SSQLS
since that feature really *rocks*.
Keep up the good work,
Viktor STARK

Mon, Nov 28, 2005 at 12:38:08AM +0100, Viktor STARK wrote:
The problem is that - if I understood things correctly - I can only
define a BLB as a std::string. And when I execute my query and try to
access the data in the BLB, it stops after the first hex 00 (which is
"normal" since it's a string). Problem is that even if I access the
data() member of the string, I only get the bytes till the first 00.

Just to make sure, you've checked the size() of the string, right?

I have a bad feeling that somewhere the data is being assigned with
operator=(), but I don't know for sure. This would take some time,
delving into custom.pl.
- Chris

Sun, Nov 27, 2005 at 08:51:30PM -0500, Chris Frey wrote:
Mon, Nov 28, 2005 at 12:38:08AM +0100, Viktor STARK wrote:
The problem is that - if I understood things correctly - I can only
define a BLB as a std::string. And when I execute my query and try to
access the data in the BLB, it stops after the first hex 00 (which is
"normal" since it's a string). Problem is that even if I access the
data() member of the string, I only get the bytes till the first 00.

Just to make sure, you've checked the size() of the string, right?

I have a bad feeling that somewhere the data is being assigned with
operator=(), but I don't know for sure. This would take some time,
delving into custom.pl.

Looks like a limitation in the conversion from Row.at() into ColData, which
takes only a char* in the constructor.

I don't know if Warren has fixed this in his private/devel tree or not.
This sounds familiar to me and I don't know why. :-)

Might take me a while before I can write a patch for this, given
time constraints. Should be easy to do, if someone wants to tackle it.
Look at Row::at(), the ColData template, and the const_string used in the
ColData typedef. Then add an operator const std::string&() to ColData.
- Chris

Viktor STARK wrote:

The problem is that - if I understood things correctly - I can only
define a BLB as a std::string. And when I execute my query and try to
access the data in the BLB, it stops after the first hex 00

This truncation bug may be fixable.

But, don't expect it to be possible to define an SSQLS with "200 floats
in binary format" and have the one BLB field be busted out into those
200 individual fields. SSQLS requires a 1:1 relationship between fields
in your structure and fields in the database.

Hope I'm just missing something obvious and I'll be able to use SSQLS
since that feature really *rocks*.

I've put your truncation bug on the Wishlist. Since it's your itch,
you're in the best position to scratch it. I don't have any idea when I
can get around to it.

Chris Frey wrote:

Looks like a limitation in the conversion from Row.at() into ColData, which
takes only a char* in the constructor.

I don't know if Warren has fixed this in his private/devel tree or not.
This sounds familiar to me and I don't know why. :-)

I don't recall anything about it. I presume that you're wanting to add
an std::string overload. There may be a reason it can't be done. We've
run into char* vs. std::string vs. SQLString vs problems before.

FYI, the only thing I have that's not checked in right now is my
investigation into Bakefile. It's marginally working, but not so much
that I'm happy with it yet. I will probably release it on the list as a
patch to the v2.1 branch first, for wider banging-on.

Mon, Nov 28, 2005 at 03:18:22PM -0700, Warren Young wrote:
Chris Frey wrote:
>
>Looks like a limitation in the conversion from Row.at() into ColData, which
>takes only a char* in the constructor.
>
>I don't know if Warren has fixed this in his private/devel tree or not.
>This sounds familiar to me and I don't know why. :-)

I don't recall anything about it.

Must be my imagination.

I presume that you're wanting to add
an std::string overload. There may be a reason it can't be done. We've
run into char* vs. std::string vs. SQLString vs problems before.

Should be fixable. Might not maintain ABI compatibility though.

The main problem is that data/size of raw field data is maintained right
up to the Row::at() conversion, where suddenly ColData has no notion of
anything but a char* in the constructor.
- Chris

Mon, Nov 28, 2005 at 03:15:15PM -0700, Warren Young wrote:
Viktor STARK wrote:
>
>The problem is that - if I understood things correctly - I can only
>define a BLB as a std::string. And when I execute my query and try to
>access the data in the BLB, it stops after the first hex 00

This truncation bug may be fixable.

But, don't expect it to be possible to define an SSQLS with "200 floats
in binary format" and have the one BLB field be busted out into those
200 individual fields. SSQLS requires a 1:1 relationship between fields
in your structure and fields in the database.

This triggered a cool idea it should be possible to write a class to
use in SSQLS, in place of std::string, that takes a std::string in the
constructor.

course, after I fix the ColData size bug. :-)
- Chris

Chris Frey wrote:
>>But, don't expect it to be possible to define an SSQLS with "200 floats
>>in binary format" and have the one BLB field be busted out into those
>>200 individual fields. SSQLS requires a 1:1 relationship between fields
>>in your structure and fields in the database.

This triggered a cool idea it should be possible to write a class to
use in SSQLS, in place of std::string, that takes a std::string in the
constructor.

Yep, that's Worthy. It's on the Wishlist for post-v2.1.

Mon, 2005-11-28 at 15:15 -0700, Warren Young wrote:
This truncation bug may be fixable.
That's good news. :-)

But, don't expect it to be possible to define an SSQLS with "200
floats
in binary format" and have the one BLB field be busted out into
those
200 individual fields. SSQLS requires a 1:1 relationship between
fields
in your structure and fields in the database.
Sure, I do understand that. I'd cast the data from the SSQLS structure
into floats after the query.

I've put your truncation bug on the Wishlist. Since it's your itch,
you're in the best position to scratch it. I don't have any idea when
I can get around to it.

Thanks.

Viktor STARK

Mon, 2005-11-28 at 17:30 -0500, Chris Frey wrote:
This triggered a cool idea it should be possible to write a class
to
use in SSQLS, in place of std::string, that takes a std::string in the
constructor.
Sounds like a good idea. Keep us posted if you make any progress on
this.

BTW, I've made some progress about the ColData size bug. I hope to come
up with something useful this WE.
As for writing the new class, mysqlpp::Date might be a good source of
inspiration, IMH

Viktor STARK