Re: [Banshee-List] GSoC 2011 Ideas from Tobias
- From: Tobias Arrskog <tobias arrskog gmail com>
- To: banshee-list gnome org
- Subject: Re: [Banshee-List] GSoC 2011 Ideas from Tobias
- Date: Wed, 30 Mar 2011 20:53:50 -0400
2011/3/30 Bertrand Lorentz <bertrand lorentz gmail com>:
> On Tue, Mar 29, 2011 at 9:53 PM, gnomeuser gmail com
> <gnomeuser gmail com> wrote:
>>
>>
>> 2011/3/29 Tobias Arrskog <tobias arrskog gmail com>
>>>
>>> First off, thanks everyone for all help so far! I end up creating two
>>> proposals:
>>> * Tracker integration for Banshee
>>>
>>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/topfs2_tobias_arrskog/1
>>
>> I talked briefly with Bertrand at the hackfest about this and it sounds like
>> Tracker might not be a natural fit for Banshee's current feature set. I
>> would personally love to see it happen but it sounds like you might want to
>> ask for elaboration on the specifics of the problems with Tracker in
>> Banshee.
>
> I don't know much about Tracker, my opinion originates from a
> discussion with Gabriel and Rob Taylor during last GUADEC :
> SQLite allows you to create your own SQL functions, that you can then
> use in SQL queries. In Banshee we have a few of those, which are
> written in C#, and are used for searches, amongst other things.
> They are defined in this file :
> http://git.gnome.org/browse/hyena/tree/Hyena.Data.Sqlite/Hyena.Data.Sqlite/SqliteUtils.cs
>
> This feature was not available in Tracker at the time. Then of course
> there's the performance aspect, ie do not make anything slower...
>
> It's been a while now, so things might have changed, and there were
> also beers involved in the discussion. ;)
> Anyway, the premise of that short discussion was "what would Banshee
> need to use Tracker instead of its own SQLite DB". I'm not sure if
> that's the idea behind the GSoC proposal, or if it's more about
> pulling and pushing data from/to Tracker and still keep our own DB.
>
> In any case, I feel it's more of an "exploratory" project, and that
> might not be a good fit for GSoC.
>
> --
> Bertrand Lorentz
> _______________________________________________
> banshee-list mailing list
> banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list (unsubscribe here)
>
I'm still very new to both Tracker and Banshee but Tracker uses SPARQL
which while close to Sql is not even remotely similar enough to share
queries. And the more I look through the code the more it seems like
Sqlite queries are everywhere.
This are the stuff I'd very much like to iron out ASAP as I mostly see
the end results and why they would be useful, you guys are in the
better position saying if its possible or not :)
What I was picturing is one of two implementation ideas either a) You
make Banshee choose one of two Database implementation at startup or
b) you use an Sqlite database (the one already existant) as a cache
database and you have either Tracker or a normal Sqlite which scanned
and filled by Banshee as the backends.
In a) you only have one main database but it b) you are free to have
as many as you want. In XBMC we are moving towards b) as we want to
use uPnP sources and multiple mysql databases as possible sources,
this may not be in line what Banshee wants and I was thinking of doing
it as a) would fit better. After seeing the code and how much Sqlite
seems to be spread out it looks like b) might be the only choice?
If going with a) (ideally b also) it would probably involve big
refactor and perfectly abstract the database interaction so that they
fill pure C# classes of data. IMO this somewhat makes sense as Banshee
doesn't really need to know if its Sqlite or not.
As for performance, function store in Sql does only make evaluation
and planning quicker, i.e. it does it once and store that. I don't
think it stores anything with the data afaik? With that I mean that it
surely must be a fraction of the time spent on the entire transaction?
Cheers,
Tobias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]