On Tue, 28 Oct 2008 12:06:03 pm Warren Young wrote:
> Russell Robinson wrote:
> > So, re-reading it and thinking (always helps), I'm wrong.
> This is what I was getting at with the wizardry comment. type_info is
> the single ugliest module in MySQL++. Hard to understand correctly,
> hard to change, and unpleasant to read. Barfbarfbarf.
Yes, there's some secret stuff going on somewhere that I cannot find (yet).
However, as it stands type_info.cpp is not orthogonal.
If you have entries for sql_varchar and Null<sql_varchar> then it follows
there must be almost-identical entries for sql_blob and Null<sql_blob>,
because, they are the same kinds of C++ objects.
> > I'll try making sql_blob the default, and see what happens.
> If it works, it'll just break something else.
> The correct solution lies elsewhere.
> The examples seem to get by without hackery here...
./exrun load_jpeg examples/logo.jpg
It gets the error:
Error: Failed to find MySQL C API type ID for N7mysqlpp6StringE
(There's the test case you wanted in a previous emai.)
I've made progress on this but I'm stuck on one mystery.
Basically, "othorgonality analysis" (what I call it) works well. If something
is "like" something else, then the code for both of them should be "like"
I've attached another patch which updates type_info.cpp.
It adds the tf_default flag to sql_blob and Null<sql_blob> and it adds some
missing code to method quote_q.
This now allows your new version of load_jpeg to execute and insert jpeg
The one *PROBLEM* is that it doesn't insert the correct data. It always
inserts 4 bytes instead of the whole jpeg.
My guess is that it's not quoting and escaping the binary data for the column.
The question is: why?
One thought was this line in method escape_q:
const type_info& ti = c_type();
It looks to me like it should be:
const type_info& ti = base_type().c_type();
However, I've tried that and it doesn't make any difference.
Obviously, this is an experimental patch because it doesn't solve the entire
Any ideas what would prevent the quotation of the binary data?
You may be right in that there's no need for further mods to type_info, but
the lack of orthogonality makes me think otherwise.
I'm happy to have an open mind on this if we can find the solution is in fact
Russell Robinson (russellr@stripped)
Attachment: [text/x-diff] typeinfoblob.patch