Add xxx_installer::upgrade($version) method so that upgrade stanzas
are separate from install stanzas. In the old code, to do an upgrade
meant that you had to re-evolve everything from the initial install
because we'd step through each version's changes. But what we really
want is for the initial install to start off in the perfect initial
state, and the upgrades to do the work behind the scenes. So now the
install() function gets things set up properly the first time, and the
upgrade() function does any work to catch you up to the latest code.
See gallery_installer.php for a good example.
Install: <module>_installer::install() is called, any necessary tables
are created.
Activate: <module>_installer::activate() is called. Module
controllers are routable, helpers are accessible, etc. The module is
in use.
Deactivate: <module>_installer::deactivate() is called. Module code
is not accessible or routable. Module is *not* in use, but its tables
are still around.
Uninstall: <module>_installer::uninstall() is called. Module is
completely removed from the database.
Admin > Modules will install and activate modules, but will only
deactivate (will NOT uninstall modules).
run faster. This fixes ticket #235.
Incidentally, refactor exif and search to use the same patterns
overall so that if you understand one, you understand the other and
they generally use the same strings for localization.
appropriate. This allows us to switch the exif value column back to
varchar and improves the way that we deal with non-utf8 data in our
embedded EXIF/IPTC data.
many separate queries.
In the process, rip out the summary column, we weren't using it.
Clean up the test, and drop the exif_records database on uninstall.
* Create Exif_Record_Model to track whether we've scanned the EXIF
data for this photo or not. This allows us to track photos that
don't have EXIF data (and won't have any Exif_Keys)
* Blow away old Exif_Keys when extracting, else we hit unique
index constraints.
* exif::_get_stats() -- before it was running the task forever
