On Wed, 2005-08-24 at 16:01 +0200, Dirk Meyer wrote: > That's why I want to add a 'root' link.
Ok, now I understand, but ...
> | / ("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.
There's an obstacle here. Object ids aren't unique globally. That is,
you can have rows with the same id in different tables. A unique
identifier for any object is the tuple (type, id) where type refers to a
particular objects_* table. So you need to record the root type as well
as the root id, which is fine, because that's how it works for parents.
The obstacle is you can't do "WHERE (root_type, root_id) IN ((1,1),
(2,2))" in sql.
So what I'm thinking of is kind of a kludge, but should work ok:
SELECT *,root_type*100000000+root_id as root WHERE root in (100000000,
100000005)
So this means we have a introduced a limit of 100 million files in the
database, or else root_id will start getting duplicates. It's probably
ok in practice, and actually I think that, given the constraints, this
isn't bad a solution.
The problem with doing it this way, however, is that we impose a
restriction that only root objects can be "offline" (or removable).
This is ok for DVDs and CDs and stuff, but for NFS drives which are
mounted under the filesystem, this scheme won't work. Maybe that's
acceptable.
> 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.
The MP3 CD title would just be the label of the CD filesystem. That
doesn't qualify as a unique identifier though, so the name attribute
would need to be this unique value. That's why I talked about uuids in
my last email. We need some way to create a unique identifier for
removable media that has nothing to do with its mount point (or fs
label).
> 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.
If it's ext2 that's easy, since we can just use the filesystem's uuid.
Maybe FAT has something similar that we can use. Even something like
filesystem creation date concatenated with filesystem size would likely
work ok.
> Fine. It would be nice if you could add this since you know the db
> code best.
Ok. Hopefully tonight.
> 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.
Yes, that makes sense. When the vfs sees a file has changed, it
invalidates all attributes automatically, and then processes the file,
removing attributes from the invalidated list as they get updated. That
way, whatever is left over is going to be the responsibility of another
app to update.
> When Freevo wants to _access_ an invalid field, it will notice it and
> generate the data on the fly.
I'm not sure this is good, because one of those attributes could be
ATTR_SEARCHABLE and could be used for queries. This means that queries
on attributes that might be invalid could potentially return wrong
results until Freevo next tries to access that field (and hence updates
it). I think it's better for Freevo (or whatever app) to update all
invalidated attributes at start time (or when it is notified to do so
via ipc), so that queries will always be working with proper data.
Jason.
signature.asc
Description: This is a digitally signed message part
