Querying Collections from dbus

[Seb Ruiz]

2009/2/19 Maximilian Kossick <maximilian.kossick at googlemail.com>:
> On Wed, Feb 18, 2009 at 3:05 PM, Ian Monroe <ian.monroe at gmail.com> wrote:
>> On Wed, Feb 18, 2009 at 3:22 AM, Casey Link <unnamedrambler at gmail.com> wrote:
>>> There have been quite a few requests lately for some way to query
>>> collections  via dbus.  Mark and I discussed this a bit on IRC.
>>>
>>> In 1.4, there was only one collection and you used SQL to query it. In
>>> 2.x we have multiple collections and they don't all use SQL - hence
>>> the QueryMaker. Obviously to provide the most robust support to
>>> scripters, amarok should expose some way to interact with the
>>> querymakers for the active collections. How feasible is this? I
>>> suspect Nikolaj and Maxx will have some clue.
>>>
>>> Additionally, Mark stressed that a simple SQL pass-through dbus method
>>> for the local collection would be helpful for testing and make some
>>> people happy.
>>>
>>> Thoughts? Any volunteers? JJ?
>>
>>
>> D-Bus not so much. I don't get why they need database access.
>> Debugging isn't enough reason, for debugging it makes a lot of sense
>> to start your own mysql server so that you can use fullblown MySQL
>> applications.  People who do complicated out-of-process things are
>> already lauching that process from within a QtScript.
>>
>> Anyways I've always thought QtScript needed a collection interface.
>> This was reaffrimed when I looked at the code for the ampache server
>> script, which of course has tons of SQL queries. This obviously isn't
>> ideal since our schema has no guarantee for stability.
>>
>> As far as feasibility, well there's nothing you can do in C++ that
>> can't be mapped into QtScript. The challenge is mostly coming up with
>> an easy-to-use API. I volunteer to implement an API someone else
>> designs. Max's idea of executing XML would be simple to implement but
>> pretty cumbersome to use. Ideally the QtScript API should be even
>> easier then the internal QueryBuilder API.
>
> Well, scripts shouldn't use XML obviously. But a XML query interface
> seems the best way to go if we want to expose this functionality using
> dbus

Alternatively, we could create our own query language, and call it
"AQL". We could support a subset of an sql-like syntax and include our
own cool stuff. Like:

select t.name from tracks t where t.collection = 'local'.

of course this is no small task, but it would allow us to provide a
non db-schema dependent interface to the collections.