Paul J Stevens wrote: > > Very interested! Though this belongs on the dbmail-dev list really. One > of my plans post-3.0 is support for user-based sharding. Not the same as > what you propose, but there may be enough overlap that we need to make > sure we don't make life hard on each other :-) >
My bad - I couldn't decide where to post this and opted for here for user feedback. That said, I'm not sure if you noticed but I committed my changes to a branch on GitHub here: https://github.com/chrisboulton/dbmail/tree/masterslave In terms of what's left to do: * Testing. I'm not running DBMail in production yet anywhere, so all I can do is test locally, using the app as best as I can. I don't know all of the code paths (having only looked at DBMail for the first time yesterday). What I need to make sure of is that there's absolutely no writes going to the slaves (which should be read-only), and that there aren't consistency issues. * Look at the CURRENT_TIMESTAMP references. I'm pretty sure these are safe with MySQL and statement based replication, but not sure about Postgres, Oracle, etc. I by no means consider myself a C programmer, so I'm also looking for feedback on my implementation. Paul J Stevens wrote: > > Being able to specify different storage backends for blobs would be > awesome! One gotcha you need to be aware of: IMAP-SEARCH. But that could > be solved by adding support for SOLR/Lucene. > Glad to see we're on exactly the same page (I was thinking Elastic Search which is built on Lucene). Either way, pluggable modules here would be great. -- View this message in context: http://old.nabble.com/Interest-in-read-write-database-pools--tp31468970p31474527.html Sent from the dbmail users mailing list archive at Nabble.com. _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
