List:Internals« Previous MessageNext Message »
From:Alaric Snell-Pym Date:May 12 2009 1:37pm
Subject:Re: MySQL Reengineering Project
View as plain text  
Excellent news!

One word of warning, though: make sure it's a series of small steps.
It's far too easy, with this sort of thing, ending up going off on
huge yak-shaving tangents. By all means take lots of small steps
towards a lofty distant goal, but make sure each step is useful in its
own right (even if just by allowing other steps to happen), or you can
get lost on a branch that will never merge ;-)

I see that a few macroscopic tasks have appeared on the Forge already,
but I'd like to add something I think could be changed for the better,
on a grass-roots level throughout the codebase:

I see a lot of methods that are called with arguments and return a
value, but most of their input and output is actually through member
fields of the object - not that the method is operating on its object
per se, but that the caller actually puts things into the member
fields, then calls the method, then inspects the results in member
fields. For example, in the storage engine API, update_row is called
with a buffer in unireg format, which it almost universally ignores
and instead uses the array of Field objects set up in the handler
object by the caller. And we spent some time in debugging our storage
engine - it would return rows fine when you did selects on the table,
but when you did certain types of join, it would fail to return any
rows, despite our logging clearly showing we'd returned rows to MySQL
- because it seems that sometimes MySQL not only looks at the return
value of rnd_next, but also checks the 'status' member of the table
object to see if the current row of the table is valid or not. So our
rnd_next had to assign success/failure to table->status as well as
returning success, and then everything worked OK. Doh.

Making the inputs and outputs of every method/function explicit,
rather than sneaking stuff in and out via members, will make the
calling interfaces between things a lot easier to read, which will
reduce the chances of developers working on a module introducing bugs!
Plus, it'll simplify the classes a lot, and make them easier to read,
as they will end up with only members that really relate to the actual
domain object - eg, the table or whatever - rather than members that
are part of the calling protocol of particular operations on the
class. Less short-term mutable state in classes means they can be
shared between threads in more and more contexts, too, as function
arguments and return values live only on the thread-local stacks!

ABS

--
Alaric Snell-Pym ACGI MIAP MBCS
Chief software engineer, GenieDB
alaric@stripped

Thread
MySQL Reengineering ProjectManyi Lu - Sun Norway12 May
  • Re: MySQL Reengineering ProjectJay Pipes12 May
  • Re: MySQL Reengineering ProjectMARK CALLAGHAN12 May
    • Re: MySQL Reengineering ProjectMats Kindahl12 May
      • Re: MySQL Reengineering ProjectManyi Lu - Sun Norway12 May
        • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectStewart Smith13 May
  • Re: MySQL Reengineering ProjectMikiya Okuno18 May
    • Re: MySQL Reengineering ProjectSergei Golubchik18 May
      • Re: MySQL Reengineering ProjectRoy Lyseng18 May
Re: MySQL Reengineering ProjectAlaric Snell-Pym12 May
  • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectJay Pipes12 May
      • Re: MySQL Reengineering ProjectJay Pipes12 May
        • Re: MySQL Reengineering ProjectAlex Esterkin12 May
          • Re: MySQL Reengineering ProjectBrian Aker12 May
      • Re: MySQL Reengineering ProjectSergei Golubchik12 May
        • Re: MySQL Reengineering ProjectBrian Aker12 May
          • Re: MySQL Reengineering ProjectSergei Golubchik12 May
            • Re: MySQL Reengineering ProjectAlex Esterkin12 May
              • Re: MySQL Reengineering ProjectBrian Aker12 May
            • Re: MySQL Reengineering ProjectJay Pipes12 May
              • Re: MySQL Reengineering ProjectDavi Arnaut13 May
              • Re: MySQL Reengineering ProjectAlex Esterkin13 May
                • Re: MySQL Reengineering ProjectJay Pipes13 May
            • Re: MySQL Reengineering ProjectMichael Widenius14 May
          • Re: MySQL Reengineering ProjectJonas Oreland13 May
        • Re: MySQL Reengineering ProjectRoy Lyseng12 May
      • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectAlaric Snell-Pym12 May
      • Re: MySQL Reengineering ProjectMats Kindahl12 May
      • Re: MySQL Reengineering ProjectMichael Widenius14 May
        • Re: MySQL Reengineering ProjectAlaric Snell-Pym15 May
          • Re: MySQL Reengineering ProjectKristian Nielsen15 May
            • Re: MySQL Reengineering ProjectBrian Aker15 May
            • Re: MySQL Reengineering ProjectAlaric Snell-Pym15 May
          • Re: MySQL Reengineering ProjectMichael Widenius6 Jun
Re: MySQL Reengineering ProjectMats Kindahl12 May
Re: MySQL Reengineering ProjectAlex Esterkin12 May
  • Re: MySQL Reengineering ProjectMasood Mortazavi13 May
    • Re: MySQL Reengineering ProjectBrian Aker13 May
    • Re: MySQL Reengineering ProjectAlex Esterkin13 May
      • Re: MySQL Reengineering ProjectBaron Schwartz13 May
        • Re: MySQL Reengineering ProjectStewart Smith13 May
          • Re: MySQL Reengineering ProjectBaron Schwartz13 May
    • Re: MySQL Reengineering ProjectAlex Esterkin13 May
    • Re: MySQL Reengineering ProjectStewart Smith13 May
  • Re: MySQL Reengineering ProjectMichael Widenius14 May