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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
