Ok, let me recapitulate: - we want to replace all auto-incremented fields with bigint fields to hold uuids in order to accomodate N-clustered databases.
- we can't directly use those uuids as UID message attributes because those are required to be 32bit, whereas uuids will need to be 64bit or longer. So where does that leave us: we will have to map uuids to messsage-uids. The simplest scheme I can come up with that is not lossy is: dbmail_messages.mailbox_idnr - dbmail_messsages.message_idnr; This is assuming that mailbox_idnr *and* message_idnr are time-based uuids. Mailboxes are created *before* they can contain messages, so mailbox_idnr < message_idnr. We only need a sequential list of uids where a uid is persistent even when other (earlier) messages in the same mailbox are deleted. We don't need uuid type message uid values. And this will do it for new installation. Consider also that uid values don't have to be unique across mailboxes, just within a mailbox. However, what if the mailbox_idnr is some /old-school/ auto-incremented value, and the message_idnrs are a mix of /old-school/ values and /new-school/ uuids. That is your typical transitional nightmare. Simplest solution I can think of is to fix those mailbox_idnrs. Search for mailbox_idnr values where (mailbox_idnr < baseline uuid as generated on jan 1st 2005) or so. Any comments? Paul J Stevens wrote: > alphanumerics won't solve anything here. > > We are still in a 32-bit headroom. Changing the visual represenatation > from base-10 to base-64 won't make any difference. > > Bloody hell, come to think of it: bigints don't fit in a 32bit space > either. Time to rethink... > > > Kevin Baker wrote: > >><snip> >> >>>I'm interested in the sorts of server-id's we can start >>>configuring for. >>>Strictly numerical? Why not alpha-numeric? What would the >>>implications be >>>of compressing the numeric time into an alpha-numeric >>>field, using either >>>base-32 or base-64 in terms of the ascending nature of the >>>id numbers, and >>>which of the fields are required to be numeric by the IMAP >>>spec. >> >> >>It would probably be ok to have alpha characters so long >>as when listed they maintain sequence properly. Below RFC. >>The advantage would be that alpha allows for 36 unique >>characters position (26alpha, 10 numeric) while numeric >>only allows for 10. With this in mind it would be great to >>have a two character position open for server id as it >>would allow for much larger server clusters with unique >>server id's. >> >> >>2.3.1.1. Unique Identifier (UID) Message Attribute >> >> RFC Unique-id Requirements Summary >> - 32-bit value (not necessarily number) >> - must be uniquie across all messages in mailbox >> - strictly ascending not necessarily contiquous >> >> >> >> >>>You're way awesome for tackling this problem! I'd help >>>more, but I'm still >>>totally swamped in work :-\ >>> >> >>Yes thanks again.... Let me know if I can help in any way, >>even if it is just research. It was actually kind fun to >>"decode" that giant RFC ;) >> >> >>Kevin Baker >> >> >> >> >> >>>Aaron >>>_______________________________________________ >>>Dbmail-dev mailing list >>>[email protected] >>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev >>> >> >> >>_______________________________________________ >>Dbmail-dev mailing list >>[email protected] >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev >> > > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
