From: Jorgen Loland
Date: February 8 2011 10:02am
Subject: Re: bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3219)
 WL#5594
List-Archive: http://lists.mysql.com/commits/130691
Message-Id: <4D5114CB.7070109@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit



On 02/07/2011 09:52 PM, Guilhem Bichot wrote:
> Hello Jorgen,
>> >I have the goal to make get_current_struct() private soon if
>> >possible. So, nobody could access "the current struct"; it could just
>> >add objects/arrays (which implicitely adds them as children of the
>> >current struct), or pass down an object/array if a function wants to
>> >add to it.
>>
>> Ok, but can I please get this patch in first?
>
> Now that the range opt patch has been pushed, it's time to think about
> this get_current_struct().
> I suggest that the current structure (Opt_trace_array), which is created
> by handler::multi_range_read_info_const(), is passed by that creator to
> seq->next(), as a third parameter named "trace_array".
> So the signature of RANGE_SEQ_IF::next() would get a third parameter
> (minor change to handler API, quite probably ok in Fuchsia).
> If that *Opt_trace_array parameter is not NULL, next() would be expected
> to add to it (and it's not deadly if the engine implementing next()
> forgets to do that: the trace will just miss information). Only the
> default implementation of next() (sel_arg_range_seq_next()) would add to
> the array (as it is now: only sel_arg_range_seq_next() adds to the
> array; quick_range_seq_next(), bka_range_seq_next(),
> bka_unique_range_seq_next() don't).
> Then get_current_struct() would be deleted from Opt_trace_context, which
> is better for isolation.
>
> What do you think of this?

That's a good idea. Is the branch stable enough for me to do this now or should 
I wait?

-- 
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway