'Export' Domain prefixing configs, knowledge-sharing

Hi Ken -

In addition to the offer I made in #234340: Generating prefixed tables for existing domains, I had another thought while setting up the domain prefixing options for my 173 tables: "Gee, there REALLY ought to be some kind of way of recording this configuration." This reminded me a bunch of the challenges I ran into when I was initially trying to figure out the db config for a multisite install as a drupal nooblet, and how long I looked (in vain) for a good guide to the choices I needed to make in that respect.

So, I wrapped these and some other ideas into a proposal: it seems like there would be a lot to be gained from adding some additional data history and exporting capabilities to the domain prefix module. I'll step you through my thought process from the beginning, as I think that's the clearest way of getting the picture I've got:

First, I think there may be some merit in creating a domain_prefix_history table; it probably wouldn't have to be anything more than a four-field table: domain_id, revision id, timestamp, and a longtext field for the serialized array of the domain prefixing config in the exact form it's recorded in the variable. Maybe a fifth field for a log message. I'm not entirely sure that there would be THAT much demand for people rolling back their db config, but when it comes to your db configuration, having some backups never EVER hurts.

I then took the thinking to the next level - in fact, a history table may not be the best way to do this. There are a couple reasons - #1, if the domain prefixes get screwed up, keeping the restoration data in the database is a little like locking your keys inside the car. Kinda. More importantly, though, is that if we go the route of saving database prefixing configuration to something like, say, an xml file in a /files subdirectory on the webserver, then that opens up a whole new range of possibilities when it comes to sharing that information, especially if, say, we were to add a log field per table/group of tables. Not only would clients probably appreciate annotations on why their db prefixing model works the way it does, but it could also be a real boon to any future developers who they may hire to work on their site.

Next turn in my thinking was towards giving back to the drupal community. Given that I can't think of any potential security or confidentiality issues that arise from sharing a db prefixing configuration, there's some nifty potential that arises from the portability of that XML file. Bottom line: those XML files, ESPECIALLY when commented, would be case studies unto themselves; in some ways, they'd be even better than case studies, because we could also gather statistical data. I don't have the knowledge to speculate as to whether it would be better to have the site send the xml config itself, or to have it simply send a notification that the file is present to, say, your site where you host the domain access API? or maybe even d.o, at some stage? I imagine the latter route would be better - exchange some temporary security protocol that allows the notified site to nab the XML file on the next cron run, and if it passes some validation tests, then it can be imported into a database of OTHER db schemas. If it's done via d.o, all the admin who created the config has to do is add their d.o username via a GUI and it can be included with the XML file; next time s/he visits d.o, they get to confirm that the XML file is theirs and that they intended to send it.

Anyway, once the data gets validated, information sorting & sharing would be cake. Obviously people will have different db configs for different reasons, but that's why we hope for log messages - and even if they don't, more information is better than NO information, which is effectively what people trying to undertake multisite installs have now. Anyway, the sky's the limit once the data's in d.o or some other central repository - we can look at aggregate statistics and develop 'recommended' prefixing configurations for differently-purposed multisite installs, and those configurations could in turn be accessed in real time by other people trying to set up their prefixing configurations. Project* could be updated to allow module developers to add recommended domain_access prefixing settings via their module's project administration page. And that's just off the top of my head.

That's the long and the short of it. Just to be clear, I'm offering to write it - if you think the idea has legs. I can't promise that I'd get to it until maybe a month from now, but it's definitely something I'd love to do.

cheers,

sam