Jay Pipes wrote:
> Mats Kindahl wrote:
[snip]
>> However, do you know of any other interfaces that work this way? I am
>> personally
>> not aware of any other, but then I don't know every corner of the code
>> like Serg
>> does. :)
>
> "External" interfaces? See all the plugin "interfaces". There's no
> enforcement of types really at all. Just passing void *'s around.
I'm using "interface" in a very liberal sense here. Type checking might improve
an interface, but it's still an interface even when passing void* around.
Compared to the rest of the server, the plug-in interface is one of the better.
> As for the internal interfaces, I would suggest cleaning up the class
> interfaces of THD, JOIN, and other major classes to enforce public
> accessors and getters, protecting private member variables behind a
> clean API. This would, eventually, make some of these classes
> semi-usable in public interfaces. Right now, the passing of the THD*
> everywhere, and THD having basically a bunch of public member variables,
> means that there is no enforcement of state changes through an
> interface. This leads to serious problems where the "internal" state of
> a THD is actually public and cannot be seen as reliable for the lifetime
> of a session's requests.
Agree.
> Another thing to think about in your refactoring efforts is detaching
> the THD from its current inheritance from Statement, Query_arena and
> ilink. Without doing this, and using encapsulation so that a THD can
> have multiple Statements, it will be very difficult to work on any
> future parallelization efforts.
Yes, disassociating threads, connections, and "statements" is something that
need to be done.
/Matz
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
