List:Internals« Previous MessageNext Message »
From:Antony T Curtis Date:April 27 2009 4:12pm
Subject:Re: WL#820 (Perl/Java stored procedures) patch
View as plain text  
On 26 Apr 2009, at 12:55, Konstantin Osipov wrote:

> Hello Antony,
>
> What's the idea with introducing class Transport?
>
> I liked the fact that you remove all traces of the embedded
> library from the non-embedded protocol (protocol.cc), but I
> couldn't understand the need to introduce an additional level of
> indirection with class Transport.

That was done quite a while ago - the intent is to preserve the  
existing functionality but to encapsulate without duplicating code. On  
hindsight, perhaps I was too aggressive in avoiding code duplication  
as it resulted in a somewhat contrived design.

>
> What does class RestoreProtocol do?

Simple/stupid utility class to restore values of thd->text/binary  
protocol. Used in earlier implementations but with later experimental  
refactorings which resulted in everything returning data in a  
select_result class, it's requirement has become somewhat unnecessary.

>
> Could you take a look at the "execute direct" connection
> implementation and class Protocol_local that is currently in 6.0
> (sql_prepare.cc), could the patch be re-based to use it?
> As far as I could understand, moving to Ed_connection would let
> you avoid code duplication in sp_instr_external, which
> currently has to copy all COM_ level commands and handle them,
> as well as manually parse SQL, as well as re-implement the
> most of the client-server protocol ;).

Ok, I must admit that I haven't bothered to examine the 6.0 tree since  
last year and I briefly look at changes in 5.1 only when it obstructs  
merges.

I will look at doing a proper refresh soon - but just keep in mind  
that I can only spare my personal time.

>
> Please do write any questions you come up with here, on this list.

Thanks. I am glad that this is eventually being examined.

>
> Thanks,
>
> PS With "virtual tables/table functions" implementation in this
> patch, which is based on MySQL 4.1 derived tables and hooks into
> mysql_derived_filling(), I'm afraid it has to be put on hold.
>
> The derived tables infrastructure that it relies on is gone in
> 6.0, and we are re-implementing derived tables as mergeable views.
> It's a bit unpleasant to our users when EXPLAIN fills all derived
> tables (or invokes all table functions) :).
>
> The issue with the taken approach to derived tables is that it
> is unaware of the optimizer cost analysis --
> mysql_derived_filling() happens during semantical analysis of the
> query, i.e. prematurely.
>
> We do have a plan for virtual tables, but first we need to re-work
> our handler (PSEA) interface to support cursors, as well
> as rework our execution layer to use cursors instead of 'handler'
> objects to work with tables. Once true PSEA level cursors are
> in place, a table function can be a sub-class of class
> Cursor. Timour is coordinating this work, while I'm doing the
> re-engineering part with the handler. With regard to progress,
> I have to admit that I'm stuck, since I haven't been able
> to get a review for a patch that was ready in September 2008.

Admittedly, I only implemented table functions because it was easily  
obtainable with relatively little code.
I will hope to see progress soon then.

Regards,
Antony.

>
>
> -- 
> kostja

Thread
WL#820 (Perl/Java stored procedures) patchKonstantin Osipov27 Apr
  • Re: WL#820 (Perl/Java stored procedures) patchAntony T Curtis27 Apr