List:Internals« Previous MessageNext Message »
From:Ingo Strüwing Date:May 10 2007 2:20pm
Subject:Re: first blob implementation for heap engine
View as plain text  
Hi Manu,

ciccettino@stripped wrote:
...
> Now I've done almost all the modifications you suggested to the patch:

Thank you very much. But as I said it would not be necessary until a
decision has been made upon your patch in general. My vote is not
sufficient to include it in the official code base. I have seen a small
amount of action, but it's still far from being decided yet. :(

>  - done a little sql file to test the new capabilities: it creates a new db, a table
> with geom column and does some INSERT, SELECT, 
> UPDATE, DELETE, ALTER; then another table with a mediumblob is created and a file
> loaded into it and then retrieved; I hope that's enough 
> for now (refer to README).

Great. Very good. That should be sufficient for now.

> About the "const char*" of hp_blobs.c functions, I imitated the style of similar
> functions in other source files: what is the problem with 
> it?

With "const char*" one promises to the caller of a function that the
function does not modify the string. So the caller does not need to make
a copy of the argument if it needs it later on.

If you modify the string, you 1. lie, 2. may cause unexpected behavior
in the callers code.

The "const" keyword allows the compiler to verify that you keep your
promise. If you cast the parameter to something without "const" you're
preparing for a potential "betrayal" going undetected by the compiler.
If you actually write to the string, you make it complete.

Can you please point me to "similar" functions that write to objects
declared as "const"? (I know of a few places where we cast a const
parameter to a non-const variable. But we never do write to it, I hope.)

> I didn't merge heap_create_with_blobs() and heap_create() because of the two
> additional parameters of the first one and for compatibility 
> with the rest of the code. Have you any suggestion on the way to do it easly?

Please let us tackle this later. heap_create() is not an interface that
requires stability, I believe. It is called from one place only (plus
from three test programs).

> Lastly can you be more explicit on the copyright problem? What may I have to do?

This problem is for later too. If you are curious, you can look at
forge.mysql.com especially http://forge.mysql.com/contribute/
There you will find licensing related stuff. If we decide that we want
to include your patch in our code base, we will ask you to sign a
license agreement. Only if you agree with the terms, we are allowed to
distribute your code together with our code under the same license terms.

Regards
Ingo
-- 
Ingo Strüwing, Senior Software Developer
MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Kaj Arnö - HRB München 162140
Thread
first blob implementation for heap engineciccettino@tiscali.it3 Apr
  • Re: first blob implementation for heap engineIngo Strüwing5 Apr
  • Re: first blob implementation for heap engineIngo Strüwing26 Apr
Re: first blob implementation for heap engineciccettino@tiscali.it6 Apr
  • Re: first blob implementation for heap engineChad MILLER6 Apr
  • Re: first blob implementation for heap engineIngo Strüwing7 Apr
    • Re: first blob implementation for heap engineIngo Strüwing17 Apr
Re: first blob implementation for heap engineciccettino@tiscali.it9 May
  • Re: first blob implementation for heap engineChad MILLER15 May
    • Re: first blob implementation for heap engineIngo Strüwing15 May
Re: first blob implementation for heap engineIngo Strüwing10 May