Alex Esterkin wrote:
> Let me play a devil's advocate role and throw in my grumpy 2 cents.
>
> First, let us clarify what exactly constitutes the public handler API. It
> is much more than the set of functions defined in the sql/handler.h header
> file. Presently, you have to include the entire transitive closure of all
> public methods of all classes used as arguments. There are many storage
> engines out there, especially the transactional and the column-oriented
> ones, that use THD member variables and member functions. Download and take
> a look at the Infobright Community Edition source code to see what I mean.
Absolutely. This is one of issues that has been brought up many times.
>
> Second, the entire MySQL code based is glued in hundreds of different ways
> by using the same classes and structures. In software architecture terms,
> MySQL has an absolutely monolythic domain model. To decouple different
> processing areas, you will have to create independent domain models for
> each, so that you could consistently implement separation of concerns.
> Presently, MySQL lacks separation of concerns: the same parse tree is used
> at every stage of query processing. On the other hand, in Postgres, a
> parse tree is represented by a Query structure (a tree of C structures), the
> query optimizer generates and considers a bunch of throwaway Path tree
> structures, then the query planner generates a tree of Plan nodes (Plan
> tree). The query execution is a state machine; Init...(_) functions
> generate various PlannerInfo structures/nodes, which are ultimately
> responsible for runtime query execution. In the Postgres world, only Query
> tree and Plan tree need to be copyable and serializable. This makes sorce
> tree organization simpler and cleaner. Without implementing such separation
> of concerns, MySQL architecture will remain monolythic. [To be fair,
> Postgres code is monolythic as well, but in a very different way]
>
> Third, for many storage engines, there will be extra software engineering
> cost of chasing your refactoring changes, especially if some of the changes
> go against storage engine's architectural assumptions.
You might be interested in taking a look at WL#3859
(http://forge.mysql.com/worklog/task.php?id=3859) and the associated worklogs.
We are basically moving towards a model with version-stable interfaces
> I wonder if the MySQL refactoring news may indicate a tug of war between US
> based and EU based Sun / MySQL teams?
Not from where I see it.
> We already have one MySQL refactoring project under way? It is called Drizzle. Is
> this a "Drizzle
> Reloaded" project?
Not really; Drizzle has a very drastic approach to the re-engineering, for good
and for worse. This is a project focused at breaking the monolithic model that
you have observed to both allow internal developers to work easier with the code
as well as making it easy for external developers to extend and alter the system
to their needs. Thus, we are not planning for a "major rewrite" (and personally,
I advice against it since we would be doing our users a disservice.)
> By the way, Drizzle can be used as an illustration of
> how easy it is to go too far: views and prepared statements are no longer
> supported in Drizzle.
Which is why this is not a "Drizzle Reloaded" project. Without speaking for
them, my observation of the Drizzle project is to attempt a drastically
different approach. The same approach has been seen when building extensible
microkernels instead of monolithic operating systems. Leaping to the same
conclusions for database management systems is not far away.
Just my few cents,
Mats Kindahl
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
