revisiting folders again

Posted on January 20, 2016

(I am currently in a similar situation to that described in my post Stop and Think. I’d rather be writing code than prose, but am so rarely able to get enough time to concentrate on it. So it’s more efficient to work ideas out as thoroughly as possible in English first. Frustrating though. :( )

I think I can improve my previous sketch for the folders model. I had this:

Folder
  name Text
  special Int
  del Bool
  del_all Bool
  del_perm Bool
  del_days Int

But we get more flexibility if we have separate times for read and unread messages, obviating the del_all flag. Also, del isn’t really needed: we could make del_days ISNULL mean “never delete”. So that gets us to something like this:

Folder
  name Text
  special Int
  class Bool
  del_read_days Int
  del_read_perm Bool
  del_unread_days Int
  del_unread_perm Bool

Note that, unlike in the previous post, the del_*_perm flags specify whether messages should be moved to Waste or the as-yet-vapourware archive. Messages from Waste and Spam (identified by their special flags) are always actually deleted. Messages from all other folders are moved.

Actually it’s easy to see how to implement the archive now: it’s just another special folder, that isn’t (normally? ever?) displayed in the folder list, but can be searched. (Search, of course, is also vapourware.)

How do my sample folders look under this scheme? Like this:

('General',  1,    't', NULL, NULL, NULL, NULL)
('Spam',     2,    't', 30,   't',  30,   't')
('Waste',    3,    'f', 60,   NULL, 60,   NULL)
('Haskell',  NULL, 'f', 1,   't',   30,   't')
('shopping', NULL, 'f', 365, 'f',   365,  'f')

Although the read / unread distinction doesn’t come in often here, it does look useful for things like Haskell: if I’ve read a message (and not saved it somewhere else) I don’t want to see it for much longer. If I haven’t read it, I might get round to it at some point: give it a month. In these examples, the del_*_perm flags are always the same. Would they ever be different?

I wouldn’t, but some people might consider setting auto deletion of unread messages from General. Hmm… suppose you wanted to automatically move read messages from General to Read? Would it be better to store the destination folder instead of the perm flags? (What happens if you remove a destination folder?)

Actually, I rather like this idea. Postgres allows a “foreign” key reference to be to the current table (and I’d assume persistent allows it too, although I haven’t checked yet). As for deleting a destination folder, at the SQL level this will by default by prohibited. Obviously the chrome would have to notice that this was going on, and offer to update folder settings for you. So that idea leads me to this:

Folder
  name Text
  special Int
  class Bool
  del_read_days Int Maybe
  del_read_dest FolderId Maybe
  del_unread_days Int Maybe
  del_unread_perm FolderId Maybe

Suppose del_read_days were 0. This would suggest that the moment a message was marked as read, it should be moved. Would this be surprising? It would be no good waiting for the router to do it, but it should be possible to arrange the code in such a way that the web interface can call the same code as the router would call to retire messages.

I think the other bit, the table to implement the many-many relationship, is pretty sound. Not quite sure what to call it though.