Hi Bernd, Am Mittwoch, den 05.07.2006, 17:00 +0200 schrieb Bernd Fondermann: > >>1) flag: are flags dynamic? I understand from your document that we need > >>to store the flag types in a table so that their ID can be used. Is it > >>needed or the flag types are statically defined in the RFC? > > I was reading RFC again carefully about this topic. Handling > > many-to-many relationships might have some drawbacks. In fact the > > predefined system flags like \Seen and \Answered can't be extended, so > > we could store them either using a binary combination or one boolean > > column per flag. > > Well, I still don't like storing externally defined constants, like > > OR-ing flags to an int value. But it might have the highest performance > > and could be quite easy to handle. What do you think? > > +1 for boolean flags. I expect more serious performance bottlenecks > elsewhere ;-) > > in the RFC the flags are string constants and have no ID attached to > them. so the implementation can choose whether or not it assigns IDs to > them.
Yes, but some of them have semantics to the server like \Seen could be automatically set, new messages are \Recent, \Deleted messages will be expunged, and \Recent and not \Seen are announced. In the case of ACL / rights, every single right must be interpreted by the server. There are already 9 rights proposed by IMAP ACL (RFC 2086). There should be rights added for quota etc. Okay it's very unlikely we are consuming a 32 or 64 bit int, but thing would get unclear. I now came to the conclusion that boolean columns, one column per flag/right is the cleanest way. The semantic is stored in the DB because of the column names. Mapping between sql and java is fixed in the statement. I think it's better than interpreting strings first, like it would be needed when using IDs of a flag or rights table. MySQL and Horde (IMP PHP webmail) are doing it the boolean column way. > > Allowing user defined flags, that are called keywords in the RFC, is an > > additional feature. (Currently milestone 5 of the roadmap draft.) IMO > > the best approach would be a one-to-many relationship here. > > > > Table name: "keyword" > > > > message_id integer the message this keyword is assigned to Of course it has to be mailbox_id and uid here. > > name varchar name of the keyword > > > > primary key (message_id,name) > > > > Maybe it is not so good having a string in the primary key. In this case > > we could add an auto-increment primary and a unique index for > > (message_id,name). > as far as I can tell, having string-based PKs is ok. I've already experienced bugs in applications with that. The string would be user entered data and there might be encoding and escaping and a version upgrade of app or db. This could lead to the situation that db rows can't be referenced anymore. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
