On Sun, 2005-08-21 at 19:03 +0200, Dirk Meyer wrote: > I should put a fxd file to images? Fxd files are known to Freevo, but > I don't want to register a special table for it.
You can register the attributes that would be stored in the fxd files as ATTR_SIMPLE for image file types. That way there are no special columns added for those attributes. > I want to get the mtime of the dir. If it is still the same, I try to > avoid os.listdir. No point in doing that. But when freevo doesn't know > about files with the extention .foo, I need to put it somewhere in the > db. It should be returned. And if I just put stuff in a generic table, > a new app knowing about this has to correct it. listdir() is pretty fast. It might end up being faster to do the listdir() and not keep track of unknown files in a separate table. It would be easy enough to test to see which approach would be faster. You might be right. My sense is for a directory with a lot of unknown files, it will be faster to do the listdir(). But I think the common use-case will be for directories with few unknown files. So it may be worth it to have that separate "unknown files" table. > So I guess I won't put non index files in the db, moving won't be a > problem. And a generic table will do the trick. Yes, you could register an "unknown" type with the vfs and store all unknown (and hence unindexed) files there. If support for a new type is added, the row would be removed from the unknown table and a new row added to the type-specific table with the new metadata attributes. This would need to be implemented at the DBOverlord level (or whatever we want to call that class :)). So it's worth doing some testing to see if it's actually faster this way to avoid listdir(). But if we find out it is worth it to avoid listdir(), the implementation won't be that difficult. Jason.
signature.asc
Description: This is a digitally signed message part
