One of the other projects I’ve been getting back on track with lately is updating our database schema setup & updating system for StatusNet 1.0.x.
1.0’s going to have a lot of little DB tweaks like changing indexes and adding a few fields to make some of our bulk queries a lot faster. We’ve also broken out more features to plugins like XMPP support and its newer AIM, MSN, and IRC cousins.
I want to make sure that setup and update of StatusNet core and plugins works easily and consistently for developers and site maintainers, and especially for those running slightly different systems than ours (such as PostgreSQL installations, which have definitely seen some regressions.)
A few weeks ago I posted some initial notes on the wiki about limitations we’ve found in practice with the Schema API that we introduced last year for plugins, and examined the possibility of adapting Drupal’s schema definition layout structure.
This gives us additional flexibility without inventing our own data structures from thin air; it’s enough data to produce live tables and DB_DataObject’s metadata, and gives us a chance to bake in support for non-MySQL backends from the beginning.
I’d love for folks working with PostgreSQL (or with other experimental backends) to poke around at my ‘schema-x’ work branch and send feedback or fixes. Thoughts and ideas about slightly-funky stuff like binary blobs, enums, and db-specific fulltext indexing are especially welcome.
For 1.0.x the only top-tier supported backends will be MySQL and PostgreSQL, but we’d love to see more!