Fork me on GitHub
  1. Deep surgery or why early optimization sucks

    When zena started, I had this idea that the “nodes” table (the one containing access information on the objects in the CMS) had to have at least one field so that some operations could be faster and we could use the field to do some searching.

    The field in question was called “name” and later changed to “node_name” (when we added property). The field soon became used for a lot of things:

    1. resolve fullpath based urls like /some/super/url
    2. export/import (used in filenames)
    3. asset resolution in css templates
    4. template inclusion in zafu (include tag).
    5. sorting
    6. test validation

    hell arrives sooner then expected

    This field that got it’s value from an obscure mixture of direct changes, the title and/or the filename (for documents) soon started to create lots of ugly waves, especially because it was cached in the children’s fullpath. In theory, having a direct access by names is nice. In practice, this means that any title change needed to be propagated to all child nodes (can be pretty slow).

    Then some multilingual sites where having strange results in sorting (because the “node_name” would reflect the value of another language) and even monolingual sites had problems when the “node_name” flew out of sync.

    getting out of the mud with boots on

    This thing has been haunting me for years but without a proper way out, other troubles would occur sot the damn thing stayed.

    And then some day we discovered that our multi-language indexing and sorting feature could be used to replace all this mess with a robust solution.

    It took me nearly a week of 10 hours/day work to remove the ugly beast and make sure everything still worked as expected (without becoming too slow). There is one huge commit if you want to have an idea of the work done.

    after the storm

    During this cleanup process, we gained titles everywhere (in urls, in filenames, paths, etc) in the language used by the visitor. This has a performance impact (one more table in queries for the title index), but we believe that it’s better to have an easy to understand system a little slower then something fast but unreliable that appears random to users.

    Thinking a system correctly right away can save a lot of time and work but sometimes, it’s just impossible to get things right on first shot. In this case I would have needed to create all the property and rubyless stuff and these things were way over my head at that time.

    If something looks weird, be prepared to scalpel it out some day and avoid depending too much on it if you can…

    Gaspard Bucher

    comments

    1. leave a comment