Jason Tackaberry wrote: >> OK, now you are saything something similar to me. All files and >> subdirs are in a tree starting at the disc itself. OK, so the disc is >> more or less a '/' node. > > Yes. One could have a more general "removable" object type for data > media (i.e. not audio CDs or DVD movies) where the name field is a > unique id that's particular to that media. That's actually kinda hard, > since the filesystem label isn't guaranteed to be unique. Well, ext2/3 > has a uuid that we could use, but that doesn't really solve a problem > since most removable media will be FAT. Does FAT have uuid as well?
I don't see the problem. Why not add one attribute to each file with the id of '/' for normal files and the id of the disc for files on a disc? It is easy, only one id. > I understand the inelegance of it. But solving this problem at the > database level is trickier than just adding an extra clause to the > query. The problem is that because objects can have arbitrary parents > that exist in other tables (a row in the objects_image table could have > a parent in objects_dir, and the next row in objects_image could have a > parent in objects_dvd), you can't just do a join because you don't know > what table to join. I don't want to join. I only want to help on select. E.g. my root dir is id 0 and the media with the id in the db 5 is in a disc, I would "select [..] where root in (0,5)". That's it. Back to the update problem. Here is an idea similar to the code in freevo mediadb right now. The problem is that when lets say MeBox noticed that a file is changed, it will update the item in the db. But Freevo stored something MeBox doesn't know about. This has two effects: first, MeBox can't update the field and second: MeBox doesn't know what the field is about and will not use it. So what about adding an extra parameter when adding attributes to the db called "auto unvalid on changed". The could be a list of the names of these variables in the global information list in the db. Lets us now say Freevo adds 'num_item = 5' as its personal information to the db with the flag 'auto invalid = True'. Now MeBox starts and notices a dir change. It will change some attributes and call 'reset invalid fields'. Now in the item is a list of invalid fileds and 'num_item' will be added to it. When Freevo starts again, there will be still the '5' as value, but it is marked as invalid. So a class covering the results should return 'None' when 'num_items' is requested. Now Freevo sees that num_items is not set (correctly) and will update the field. When Freevo ets num_items again, this field will be deleted From the list of invalid fields. How does that sound? Dischi -- Microsoft is not the answer. Microsoft is the question. 'No' is the answer!
pgpHxrhkoBgeZ.pgp
Description: PGP signature
