-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading BLOB from SQLite3 no longer working #1173
Comments
Thanks for reporting this, it's definitely a regression and should be fixed because I don't see anything wrong with this code. I thought we had some testing code doing essentially the same thing, but I was clearly wrong. It would be great if you could please make a patch adding the (now) failing test case, this will help debug/bisect it and will ensure that it remains fixed in the future. |
Sure, I'll look into adding a test. Will take a while to get familiar with your testing setup tho. I think the underlying "issue" or "cause" is that soci/include/soci/type-holder.h Lines 338 to 351 in a55c809
There's a comment indicating that this is due to blob being non-copyable. Seems like this was introduced in commit ae07cd5. |
You can't obtain a BLOB as a string anymore. You need to do soci::blob blob = v.move_as<soci::blob>("my_column"); Relevant test case for this: soci/tests/common/test-lob.cpp Line 643 in c5678e1
Quoting from #992:
see soci/tests/common/test-lob.cpp Lines 338 to 716 in c5678e1
@vadz In order to restore backwards compatibility with the |
@Krzmbrzl Thank you for chiming in on this.
|
Yes, I'd like to do this, the code in the original code example looks fine to me and I think it's perfectly reasonable to represent (C)LOBs with
Do you understand how this worked before?
I don't think this warrants a warning, there are plenty of use cases when your BLOBs are not all that huge where this is fine. And anybody working with gigabyte-sized BLOBs should hopefully already understand that loading them in a string is not the brightest idea. |
The Lines 112 to 125 in c5678e1
I had something in mind about BLOBs being recognized as string types internally, but I don't think that is actually true... I'm going to look this up and see if I can write a fix for this issue. |
"Suitable" means that the container uses contiguous storage in memory and holds entries of type T where sizeof(T) == 1. If this is given, then the blob's data can be copied into a new instance of such a container, which is then returned in the row::get<>() call. This restores the previous possibility of reading blobs into objects of type std::string but also generalizes the concept to any suitable container (such as std::vector<unsigned char>). Note: The check for whether the given container object uses contiguous object storage is based on its iterators being classified as random-access iterators. This is not a perfect check as in principle there could be random-access iterators that don't iterate a contiguous memory region. However, for typical containers this is very unexpected as this would typically lead to rather inefficient access patterns when making use of the random-access capability. A container that is wrongly determined to be contiguous will likely result in a program crash due to a segfault. Fixes SOCI#1173
Turns out that this has been a lot more straight forward than I expected :D The issue at hand is fixed via #1189 |
Hi,
I've updated an application using SOCI from
9bcc5f8a9181886f4c73ea5b4671b35d8722cb3a
toa55c80984a447bf8c788a7d6a23ff93c022069fa
.The only problem I encountered so far is with regards of reading a
BLOB
from an SQLite3 database.Previously, the application did this (inside of a custom/user type conversion):
Where:
my_column
is an SQLite3 column of typeBLOB
v
is an lvalue reference tosoci::base_type
This used to work well. However, after the update the code is throwing an
std::bad_cast
insoci::details::holder::get()
(called bysoci::row::get()
).According to the git log there have been some activities around blob support.
What is the new, correct way of reading (and writing!) a blob to/from SQLite3?
The text was updated successfully, but these errors were encountered: