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)? 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? -- my place on the web: floss-and-misc.blogspot.com _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
