[Nepomuk] heavy duty query visualization

[Marco Martin]

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)

> > * 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

> >  * 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


-- 
Marco Martin