Jason Tackaberry wrote:
> 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.
I know. I was thinking about making root always the same type, but
that sucks. An audio disc is different from the root of my fs. BTW,
how to find a disc? Is a disc always a 'removable media' or are DVDs
and AudioCD different?
> 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.
Yes, that's a bad hack. I guess the best solution is to have a
mountpoint.
table mountpoint
int id unique
type string
rootid int
So for an audio disc with the entry 'removable', type is removable and
rootid the id. So we point to this table for mointpoint to have one
unique table for all mountpoints.
>> 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).
See above. AudioCD is a dir as _content_ from an entry in mointpoint.
>> Fine. It would be nice if you could add this since you know the db
>> code best.
>
> Ok. Hopefully tonight.
Cool.
> 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.
Maybe I can't. It sounds strange, but sometimes it is much easier to
do stuff later. Maybe a searchable attribute can't be auto invalid.
Dischi
--
AIRPORTS: A place where people hurry up and wait.
(Terry Pratchett, Wings)
pgpNRKIQRbBe7.pgp
Description: PGP signature
