[Nepomuk] heavy duty query visualization

[Sebastian Trüg]

On 10/17/2011 12:10 PM, Marco Martin wrote:
> On Monday 17 October 2011, Sebastian Trüg wrote:
>> Hi Marco,
>>
>>>
>>> * lazy loading: if i do a query with really a lot of restults, would be
>>> possible to limit it like a relational database, to know how many results
>>> there are, asking for the first 10, then from 11 to 20 and so on? (if a
>>> query has something like 2000 results that would be hady;)
>>
>> There are Query::setLimit and Query::setOffset which can be used here.
> 
> uhm, but is it possible to know how many results the query would had if there 
> was no limit? (like, how many "pages" the result will be)

Well, you can use Query::CreateCountQuery to get the number of results
beforehand. Or using QueryServiceClient rely on the resultCount signal.
Maybe we can even improve this. ATM there is only a count in case that
the limit is 0. We could change that. Then you would get the total count
with each page query.

>>> * sorting: is it possible to directly sort the results based on one of
>>> the properties? in this case i wouldn't have to load the whole model in
>>> memory from the beginning
>>
>> Sorting is quite complex since you can sort by pretty much anything. In
>> the query API this is done by setting sort weights on the ComparisonTerm
>> instances.
> 
> will try that
> 
>>> qml. What i'm thinking to do here is:
>>>  * pass queries by string, so with the more limited desktopquery
>>>  language.
>>
>> Then this would have to be extended to include all kinds of things like
>> sorting and limits and so on. That seems rather pointless.
>> Don't we have some automatic binding creation like we have for python?
> 
> there were javascript binding generators..
> bit nothing of that is probably going to work in qt5, since it will probably 
> be possible only to have bindings to qobjects subclasses, and wille be 
> possible to create them only from qml, not js (yes, i know how sick is that 
> :p)
> 
> so, since we already depend from quite a bit of qtscript and bindings to 
> primitive types, i'm a bit uneasy adding more stuff that could have to be 
> ported away in an hurry.
> 
> it can be tried tough

I see. Not great.

>>>  * expose to js some functions to limit the results, like limitByType(),
>>>
>>> limitByActivity() limitByTag() etc. this will with the c++ api add the
>>> needed parameters to a query precedently created from a string
>>
>> Impressive how ugly things need to become just so this js stuff works. :P
> 
> yep :/
> in the end will depend how much complex "real world" queries will end up.. 
> with simple ones, would be a really simple and nice api, it could become 
> something ginant and unmaintainable pretty quickly tough, we'll see
> 
>>> * what queries are possible? how? I think many of the queries we will
>>> need will be to build things tagcloud-ish, so besides a proper tagcloud
>>> that has been possible to do in nepomuk since a while, other needed
>>> things could be
>>>
>>> series of result like:
>>>   * resource type, number of occurrencies
>>>   * rating, number of occurrencies
>>>   * date interval (like month) number
>>>
>>> and so on. is this easily feasible? (this will probably go in the
>>> dataengine, not in the model)
>>
>> Do you mean feasible in C++? Then the answer if of course "yes". If you
>> say feasible in the desktop query language, then "no".
> 
> was meaning both, so ok, will need some kind of c++ binding as well

ok

Cheers,
Sebastian