Difference between revisions of "User:Djce"
m (21 revision(s))
Revision as of 10:15, 15 March 2009
However it's been a while now since I seriously hacked on the server (late 2004 I think it was) - these days I tend mainly to do whatever's necessary to keep things running smoothly and to keep the service available, rather than hacking on new features or bug fixes.
Things I'm working on, or would like to work on
The fun bit: moved to ReplicationRevampFeature.
Other Replication Changes
- We could probably do with changing the filesystem structure of replication packets, so that we get smaller directories
sprintf "pub/musicbrainz/data/replication/replication-%d.tar.bz2", $SEQ
- starts to get iffy after, say, 10000 hours (approx 14 months)
sprintf "pub/musicbrainz/data/replication/%d/replication-%d.tar.bz2", int($SEQ/1000), $SEQ
- starts to get iffy after approx 1000 times that (over 1000 years)
- Needs new code, both at the master site and all the slaves. A whole release almost seems like overkill... maybe commit the change to the release branch, update the master, and ask the slaves to do an "svn update" at their end? Either way it'll need to be announced via mb-datafeed beforehand.
- Will cause a "spike" when next mirroring to OSL@OSU. Still, it's a smaller spike than our twice-weekly full exports.
- In general: replication slave "with hooks"
- make it easier to run a replication slave with "hooks" for doing "stuff" with the changes
- should be possible to use either a near-real-time feed, or the packets
- would need hooks for "row inserted", "row updated", "row deleted"
- if the slave could be divorced from a SQL database, would also need a hook to read (the non-SQL equivalent of)
User Email Verification
Moved to EmailVerificationFeature.
Regarding deletion: ideally if a user's email expires (see EmailVerificationFeature), then they log in > 1 year later, it would be nice if the message telling them about the expiry was still there.