On Wed, 2005-08-24 at 10:49 +0200, Dirk Meyer wrote: > 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.
All objects already have an attribute that refers to their parent.
That's not what I was wondering about. We need to find a way to create
a unique id for parents. On filesystems that's easy, because we use the
path. But we can't do that for removable media since the mount point
isn't reliable. So for DVDs, it's easy to generate a unique id, but
what about CF cards, or USB devices? Is it sufficient to use the
filesystem label? Probably not. ext2 filesystems have a uuid we could
use to differentiate various removable media, but most of those will be
formatted with FAT, so does FAT have a similarly unique id to use? I
figured Freevo has a solution to this now.
> 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.
I'm not sure I follow what you mean. One or both of us might be
misunderstanding the other, or the problem. :)
The issue we're talking about here is that for queries (other than
queries for all files with a specific parent [e.g. list all items in
directory foo]), we can't easily eliminate files which aren't available
because they're stored in removable media in the sql statement. For
example:
/ ("dir", 0) parent=NULL
+-- data ("dir", 1) parent=("dir", 0)
+-- mp3 ("dir", 2) parent=("dir", 1)
+-- Enya ("dir", 3) parent=("dir", 2)
+-- May_it_Be.mp3 ("audio", 0) parent=("dir", 3)
MP3 CD title=Enya ("removable", 0) parent=NULL
+-- Watermark ("dir", 4) parent=("removable", 0)
+-- 09_River.mp3 ("audio", 1) parent=("dir", 4)
So, all objects a represented by the tuple (type, database_id). So
let's say we want to do an audio search for artist=Enya. We can see
there are 2 rows in the objects_audio table from the above layout. Both
of them match artist=Enya. But the MP3 CD isn't in the drive right now,
so it's not available. How can we eliminate 09_River.mp3 from the
results in the sql query? The id that's not available is ("removable",
0). But the parent for 09_River.mp3, which is the result that will be
returned, is ("dir", 4). We don't know that ("dir", 4) isn't available
until we traverse its hierarchy until we reach the top. Only if all the
objects in its tree are available can we include this row.
I don't see any easy way to do this except in python code. Even that
will require a whole bunch of selects to get each object's parent tree.
(Luckily those selects will be fast, since they're on indexed fields,
and they will be cached.) But I don't see how to even help this, as you
say, in the select statement.
> 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
Ok, so when you register attributes for a type, you set a flag whether
that attribute gets invalidated when the object is changed. Maybe
ATTR_INVALIDATE_ON_CHANGE flag. That sounds reasonable.
> '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.
I think it might be better to keep a table of all invalidated
attributes. When MeBox updates a row, it invalidates one or more of the
attributes (the ones that Freevo uses), and those attributes get put
into the invalidated attributes table. Then when Freevo starts (or
maybe freevo cache), it can ask the vfs, "Tell me what attributes are
invalidated." This is similar to the log idea, except it's a bit more
detailed since you know what attributes have been invalidated. That way
the application responsible for that attribute can update it and tell
the vfs "ok, this attribute isn't dirty anymore, you can remove the row
from the 'invalid attributes table'"
Jason.
signature.asc
Description: This is a digitally signed message part
