Re: [Tracker] support for other database backends?

[Ivan Frade <ivan frade gmail com>]

Hi,

 No, the graph abstraction is not the problem.

 Although the code is pretty modular (all the db specific code is in
libtracker-data), changing the database engine is a far from trivial
task. There are assumptions about sqlite everywhere and everything was
designed to squeeze the performance of that specific engine.

 For example, libtracker-sparql is using direct access to sqlite for
reading and the tracker-store daemon via dbus for writing. Postgres
has a client-server architecture itself... that means a heavy
rewritting of libtracker-sparql internals or losing performance in an
extra IPC roundtrip.

 Do you have any specific reason for postgres? Some people tested that
(for mobile devices) and the conclusion was that sqlite is ok: we are
in the "comfort zone" of sqlite, so postgres wouldn't give us any
sensibly better results.

 Regards,

Ivan

On 5/7/12, Alexander Kanavin <alex kanavin gmail com> wrote:
> 2012/5/7 Daniel O'Connor <daniel oconnor gmail com>:
> > > how feasible would it be to make tracker independent of the underlying
> > > database engine, so that other database backends (for example
> > > postgresql) could be used?
> > Given the data is graph based, I don't think you'd get far with plain
> > postgres...
>
> Er, tracker is sqlite based and sqlite is a basic RDBMS. I don't think
> that building a graph abstraction is a real obstacle here. Am I
> missing something?
>
> --
> Alexander
> _______________________________________________
> tracker-list mailing list
> tracker-list gnome org
> http://mail.gnome.org/mailman/listinfo/tracker-list