Re: [Tracker] Database access abstraction

[Jamie McCracken <jamie mccrack googlemail com>]

On Mon, 2008-11-03 at 15:30 +0100, JÃrg Billeter wrote:

> What is your opinion on my proposal to introduce a TrackerService (or
> TrackerResource) class - similar to the GFile interface in GIO - and use
> that throughout the API where we currently use path, uri, or service id?

the big disadvantage of this is that we end up supporting and coding in
more paths through the code and more SPs - not sure if its worth it
especially as in a lot of cases we will be supporting both uri and ID
params where we only ever use one

The indexing calls will all be ID based except for the call to check if
a file is up to date which is obviously URI driven and to get the ID for
a URI

The dbus calls and user api will all be URi driven

You should use that as a guide to work out which param type is needed

Also note we want to avoid issuing two sql calls on the same row (EG one
to get the ID and another to perform some action on that row with that
ID - this should all be done in one call) so making the API all ID
driven and fetching IDs separately is not an option

when we flatten tables, the metadata in that table will be directly
updateable by both uri and ID so we will want to have two separate SPs
for doing that ina n optimal fashion

jamie