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 > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
