[Nepomuk] Result sorting with Nepomuk Querylib

[Sebastian Trüg]

On 09/18/2011 11:37 PM, Vishesh Handa wrote:
>     >     This is what you do:
>     >
>     >     ComparisonTerm term(NAO::lastModified(), Term());
>     >     term.setSortWeight(1, Qt::DescendingOrder);
>     >     Query query = ResourceTypeTerm(PIMO::Note()) && term;
>     >
>     >
>     > Now, why would anybody in their right mind think of using a
>     > ComparisonTerm, when one is not comparing anything?
> 
>     Yeah, ComparisionTerm started out for plain comparision but turned out
>     into the general purpose term for anything that includes a property....
>     maybe a new name for 5.0?
> 
> 
> Yes, please. Any ideas for a new name?

PropertyTerm? RelationTerm? No idea.

> While we're on the subject of 5.0, maybe we could make the term in
> ComparisonTerm (const Types::Property &property, const Term &term,
> Comparator comparator=Contains) optional.

yes.

>     > It would be so much easier to have something like -
>     >
>     > Query q( term );
>     > q.addSortProperty( NAO::lastModified(), Qt::DescendingOrder ); // the
>     > weight is optional
> 
>     You are right for this example. But think about sorting by some variable
>     somewhere down the graph. Artificial example:
> 
>     ComparisionTerm t1(NAO::lastModified(), Term());
>     t1.setSortWeight(1);
>     ComparisionTerm t2(PIMO::isRelated(), t1);
>     Query q(t2);
> 
>     How would you express that with your API? We could of course add a
>     shortcut/convenience method which internally creates a ComparisionTerm
>     (actually that is what requestproperties are now)...
> 
> 
> I wasn't proposing that we remove the ComparisionTerm::setSortWeight
> function.
> 
> We need both. Your version of sorting using Comparison terms is very
> powerful. It just isn't convenient for simple use cases.

agreed. Will you create a branch in nepomuk-core. :)

Cheers,
Sebastian