Re: [Tracker] Tracker and SQLite

[Tshepang Lekhonkhobe <tshepang gmail com>]

2009/1/23 Martyn Russell <martyn imendio com>:
> Tshepang Lekhonkhobe wrote:
> > On Fri, Jan 23, 2009 at 12:12 PM, Martyn Russell <martyn imendio com> wrote:
> > > Tshepang Lekhonkhobe wrote:
> > > > On Thu, Jan 22, 2009 at 10:50 PM, Martyn Russell <martyn imendio com>
> > > > wrote:
> > > > > If we wanted to write another backend, we would have a lot less work than
> > > > > before of course, but the connection management would need writing. This
> > > > > part is quite tricky for SQLite. We can write a more generic interface
> > > > > here
> > > > > if we need to and if we find it makes sense depending on future
> > > > > requirements.
> > > >
> > > > Is there things specific to Tracker that SQLite is incapable of
> > > > providing that would necessitate such a move in future? That is, do
> > > > you currently to hack around such inadequacies, or is SQLite (with its
> > > > FTS) up to the task?
> > >
> > > There are no hacks for this. It is simply that we have multiple databases
> > > and they are not all stored in the same place. That coupled with the fact
> > > that some databases have to be attached to other databases to be usable,
> > > means we have complex management code depending on what part of Tracker
> > > needs database access and for what use (reading/writing).
> > >
> > > If this was all done using one database in PostgreSQL, for example, then
> > > this management of the databases changes somewhat.
> >
> > So I suppose SQLite is limited in that sense (Me not too familiar with
> > db tech, so excuse me for poking too hard)?
>
> Well, the same limitation is also a strength in other areas. This is something that you have to evaluate of 
> course when you choose this model. You could instead just use one SQLite database instead of many if you 
> wanted to.

Why not just use one db? Fragmentation?

> > What of networked Tracker? I just browsed through SQLite docs and that
> > makes me think there'll have to be a move to a client/server db in
> > such a case since SQLite wouldn't be suitable if multiple clients
> > connected to it, especially if those clients had write access?
>
> This is true. But we don't have multiple clients connecting to the database itself, just the daemon which 
> talks to the database. This is needed because the daemon knows about "state" and can control things from 
> there too. When I say state, this includes a myriad of things, battery state, removable media state, paused 
> state, etc, etc.
>
> --
> Regards,
> Martyn



-- 
my place on the web:
floss-and-misc.blogspot.com