On Sun, 2005-08-21 at 18:25 +0200, Dirk Meyer wrote: > and... > > Jason Tackaberry wrote: > > def dir(self, dir_id): > > # XXX: this isn't how you'd want to do this, just testing ... > > results = [] > > for type_name, (type_id, type_attrs) in self._file_types.items(): > > [...] > > return results > > This also doesn't look good. Maybe we should store inside a dir what > kinds of files are in the dir. This would reduce the query.
Yes, you could easily keep that information in the directory row. You might save an extra 50 microseconds by doing so. :) (Notice the XXX comment at the top of that function, however. I was just testing.) > Still, what happens to bad files kaa.metadata can't parse? Where > should I add them? A guess a 'generic' table needs to be added. But > again: what happens when a file is identified later and is moved from > 'generic' to 'image'? Or add them to the image (or whatever) table, and just not fill in those attributes. The application should be able to handle such cases anyway, it seems to me. I didn't really foresee putting into the database files which aren't indexed (or file types which aren't known). What would be the point? I suppose if you want to avoid a listdir(), but does avoiding listdir() really save a whole lot in the common case? I know you want to make directory lists as fast as possible, but obviously you can't sacrifice correctness, and some things just aren't worth the added complexity. I think we should leave some of this fruit hanging on the trees for now. Let's get the basic approach figured out first, keep note of areas that we could optimize, and do optimization later. Things like keeping track of what file types are in a certain directory can be added later without an architecture overhaul. (And in practice, something like that might not even help much anyway.) Jason.
signature.asc
Description: This is a digitally signed message part
