Open Tectu opened 1 week ago
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::details::holder::get()
is clearly intentionally throwing when the type is db_blob
:
https://github.com/SOCI/soci/blob/a55c80984a447bf8c788a7d6a23ff93c022069fa/include/soci/type-holder.h#L338-L351
There's a comment indicating that this is due to blob being non-copyable.
Seems like this was introduced in commit ae07cd546ee3f21b7dc1be6ff36be5593ccb4a67.
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?