Re: [Tracker] URI support

[Jürg Billeter <j bitron ch>]

On Tue, 2008-11-18 at 08:48 -0500, Jamie McCracken wrote:
> On Tue, 2008-11-18 at 13:55 +0100, JÃrg Billeter wrote:
> > Hi,
> >
> > Tracker currently uses a mix of local file paths and URIs and they are
> > used in different encodings and sometimes split into dirname and
> > basename and sometimes not. I've been working on the uri branch in SVN
> > to clean up the confusion.
> >
> > The Path column in the Services table has been replaced by a Uri column
> > which stores the full URI, not just the dirname as was the case before.
> > The Name column stays the same but is not used anymore to identify a
> > service. To accommodate the database changes, I had to increase the
> > database version, which means that Tracker will perform a reindexing.
> > Functions in libtracker-data that had dirname and basename parameters
> > now have a uri parameter as they are not only used for files.
>
>
> pls restore path and name (and composite index on the two) in db  - we
> need this so we can quickly find files in a particular folder. 
>
> that was the only reason they were split up like that in the db
>
> also would be very difficult to find files in a directory excluding
> subdirectories if we just stored URI and not path/name

The issue with that is that this will not work for URIs in general, it
only works for some URI schemes. If you keep the split, Tracker won't be
able to support generic URIs. In my opinion, we should better try to
find a solution to the mentioned issues.

Are you sure that searching files in a particular folder will be
significantly slower? The Uri column is indexed, searching for items
starting with a specific base URI should be very fast. I can perform
benchmarks if necessary but I don't see a reason why a UNIQUE (Path,
Name) index should be faster than a UNIQUE (Uri) index for that query.

Searching files in a directory excluding subdirectories will be a bit
more complicated. I don't know of a use case for that right now. Can you
describe where this is useful, so I can try to find an alternative
solution for that, then. Many other queries are quite a bit simpler with
the full Uri column.

JÃrg