2009/1/23 Martyn Russell <[email protected]>: > Tshepang Lekhonkhobe wrote: >> >> On Fri, Jan 23, 2009 at 12:12 PM, Martyn Russell <[email protected]> wrote: >>> >>> Tshepang Lekhonkhobe wrote: >>>> >>>> On Thu, Jan 22, 2009 at 10:50 PM, Martyn Russell <[email protected]> >>>> 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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
