List:MySQL++« Previous MessageNext Message »
From:Russell Robinson Date:October 28 2008 1:49am
Subject:Re: Patch for ssqls null blob deficiency
View as plain text  
Hi,

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...

Not now.

Try:
	./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" 
too.

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 
images.

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 
problem.

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 
elsewhere.

-- 
Russell Robinson (russellr@stripped)

Attachment: [text/x-diff] typeinfoblob.patch
Thread
Patch for ssqls null blob deficiencyRussell Robinson27 Oct
  • Re: Patch for ssqls null blob deficiencyRussell Robinson27 Oct
  • Re: Patch for ssqls null blob deficiencyWarren Young27 Oct
    • Re: Patch for ssqls null blob deficiencyRussell Robinson27 Oct
      • Re: Patch for ssqls null blob deficiencyWarren Young28 Oct
        • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
        • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
          • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
            • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
              • Re: Patch for ssqls null blob deficiencyWarren Young28 Oct
                • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
                  • Re: Patch for ssqls null blob deficiencyRussell Robinson28 Oct
                    • Re: Patch for ssqls null blob deficiencyWarren Young29 Oct
                      • Re: Patch for ssqls null blob deficiencyRussell Robinson29 Oct
                        • Re: Patch for ssqls null blob deficiencyWarren Young29 Oct
                          • Re: Patch for ssqls null blob deficiencyRussell Robinson29 Oct