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 <[email protected]> wrote: > 2012/5/7 Daniel O'Connor <[email protected]>: >>> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/tracker-list > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
