Jason Tackaberry wrote: > My thinking is very much in line with dischi's. Have a table for each > file type. These tables will have columns for important metadata (i.e. > metadata that you'll want to search on later). These tables will also > have a pickle column to store attributes we're not interested in > searching on.
But my idea also has one global table. E.g. when I do an os.listdir to get the basic data, I do not know the file type. I know the type later. So later I need to move a file to the image table. > But I extended this approach further by making everything dynamic. The > vfs handles reconstructing the database tables as needed. The > application registers file types and attributes for that filetype with > the vfs. If those attributes are already registered, this is > essentially a no-op. Otherwise, it will rebuild the tables as necessary > to reflect the new attributes. And there should be a table for all the other unknown files. > This registers the type "image" with the vfs, and those attributes > (width, height, etc.) of the given type and attribute flag. All of > those attributes will get separate columns in the table. If I had used > ATTR_SIMPLE, they wouldn't have columns but would be stored in the > pickled dict. So what happens when you use the mediadb from a different project and you don't register a type. Can you still get the files as "normal" files? > As for separate process vs. separate thread, my experience with sqlite > is that locking is cumbersome and I had run into problems. We have to > keep in mind that multiple processes will want to access the vfs (like > the web server, or record server, or whatever). Reading isn't so bad, > but if multiple processes want to write to the vfs, it could cause > problems with locking. We could make the vfs server run as as thread in > the main application so that client calls for Freevo's UI will be as > fast as possible, but for the record server and web server, some IPC > method should be possible. I'm not 100% sure what the best way to do > this is, but we need to keep it in mind. I keep that in mind. > Anyway, try out the attached code. The class there, DBOverlord (whose > name is obviously kind of a joke :)), just handles database stuff. At > that level, it has no idea about the filesystem. That is, layered on > top of that would be the actual VFS, which does know about the > filesystem and can stat files, walk trees, etc., and plugged into the > VFS would be modules to handle indexing the specific file types. Very nice. I will play with it. Dischi -- A lecture is a process where information is passed from the notebook of the lecturer to the notebook of the student without necessarily passing through the minds of either.
pgpbOXbdlKQwX.pgp
Description: PGP signature
