Re: [Tracker] Database access abstraction



JÃrg Billeter wrote:
On Mon, 2008-11-10 at 15:20 +0000, Martyn Russell wrote:
Jamie McCracken wrote:
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
True.

We could actually just:

  typedef GFile TrackerResource

For now just to keep it something internal which can change. That way
APIs stay the same and we do operations on the resource (or GFile if we
explicitly know it is a GFile).

I don't quite understand how this would help. Either we say it's always
a valid GFile, then we could directly use GFile in the API, however,
this might be problematic for e-mails and possibly other resource types.
Or we say it doesn't have to be a valid GFile, and then we won't be able
to use any g_file_* functionality, which means that we need our own
interface/class TrackerResource. Am I missing something?

The idea was to keep the API the same but be able to interchange what
the resource represents if we need to at a later stage with a little
more ease.

I agree with your points. I am not sure if G_IS_FILE() would actually
work for us here, if so, that could be utilised.

But ultimately you are right.

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
I just had some crazy idea for a second there about perhaps having a
unique ID (like an MD5SUM) for each path which is the service ID in the
database (instead of auto incrementing it) - so you can always get the
ID easily without needing extra DB look ups. Am I on crack or is this
work investigating? Ignore me if it is :)

I don't think that this would improve the situation a lot compared to
just using URIs. As far as I can tell, we would have to store the hashes
as strings as reduction to 64 bit integer is probably not sensible due
to possible collisions (and also with 128 bit MD5 we'd have to think of
a way to handle collisions). And if we store IDs as strings, we lose the
performance benefit.

Yea, it would have to be an integer not a string. Oh well, :)

-- 
Regards,
Martyn



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]