Re: [Tracker] URI support

[Jamie McCracken <jamie mccrack googlemail com>]

On Tue, 2008-11-18 at 15:00 +0100, JÃrg Billeter wrote:
> 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.

It should work fine with generic URIs - they can all be decomposed to a
path and name. Remember path is just a string and has no particular
meaning in tracker

> 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.

well I cant say for sure it will be slower as btrees store it in
alphabetical order but as I said thats not the only reason for it...

> 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.


file manager is the use case im thinking of (not sure if it applies to
philip's tracker powered file manager thingy? But even so i plan on
creating one!)

theres just no way you can do it fast and efficiently without separate
path/name

I accept it makes the code a little more complex but its worth it for
the use case IMO

jamie




> JÃrg