Jason Tackaberry wrote: > I'm not sure I follow what you mean. One or both of us might be > misunderstanding the other, or the problem. :)
Maybe.
> 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.
That's why I want to add a 'root' link.
| / ("dir", 0) parent=NULL, root=0
| +-- data ("dir", 1) parent=("dir", 0), root=0
| +-- mp3 ("dir", 2) parent=("dir", 1)
| +-- Enya ("dir", 3) parent=("dir", 2), root=0
| +-- May_it_Be.mp3 ("audio", 0) parent=("dir", 3), root=0
|
| MP3 CD title=Enya ("???", 5) parent=NULL, root=5
| +-- Watermark ("dir", 4) parent=("removable", 0), root=5
| +-- 09_River.mp3 ("audio", 1) parent=("dir", 4), root = 5
You see. You know what discs are in the drive to get the id. That's
all.
Question is: what is MP3 CD title? If it is a removable, maybe we
should name it mountpoint? And the ("dir", 0) also belongs to a mount
point.
> 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 have no idea. For discs in is timestamp+label. That has to be
unique. But I have no idea what uniwue id may be on an usb drive. We
could use some usb attributes, but sticks from the same vendor would
be shown as the same. So yes, we need to find something there.
>> 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.
Fine. It would be nice if you could add this since you know the db
code best.
>> '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."
I was thinking of an easier way. The mediadb knows when a file
changes. It just sets everything if ATTR_INVALIDATE_ON_CHANGE to
invalid and calls the callbacks to add data (here MeBox). MeBox will
update variables it knows about and keeps the rest as it is.
When Freevo wants to _access_ an invalid field, it will notice it and
generate the data on the fly.
Dischi
--
How can something be 'new and improved'? If it's new what was it improving on?
pgprIntuoTU2E.pgp
Description: PGP signature
