In D14591#303665, @ervin wrote:

I think it should be async like the rest, I understand it makes some things more complicated in the case of tooltips, but if we use something else than tooltips to display that information we'll need to update when the backend signals a change anyway.

It's more complicated at two levels. In the implementation and in the usage ;)
Let's talk about implementation first.

I need to go up the tree (of tasks) until I get to the project. Right now I do that with the full collection cache at hand, no problem.
IIUC, the live query mechanism will call my predicate with one item at a time, and I get to say "yes, keep this one". But that can't work if the predicate is called for the project before it's called for an intermediate parent task. I won't be able to say "yes this is my project" until I get the intermediate task which is the missing link to my child task.
Unless I'm missing something, I'd say the current framework for live queries isn't adapted to those needs.
I could of course still use m_cache->items(item.parentCollection()) in the predicate but that's crazy, right? There's no point in looking in ALL items every time the predicate is called with ONE item, this would amount to doing N times what can be done a single time...

It seems to me that we need a live query that calls (just once, not once per item) a method (one that returns a Project::Ptr, not a bool) whenever the collection has changed.
Using the cache, that method can right away return the project (if found).

It's an excellent start though! Looking forward to it, since we also have the findContexts for tasks it'll "just" be about channeling that information in the various models. :-)

When you say "we also have", do you mean this?

TaskQueries::ContextResult::Ptr TaskQueries::findContexts(Domain::Task::Ptr task) const
{
    qFatal("Not implemented yet");
    Q_UNUSED(task);
    return ContextResult::Ptr();
}

That's an interesting concept of "having" :-)

In D14591#304153, @dfaure wrote:

In D14591#303665, @ervin wrote:

I think it should be async like the rest, I understand it makes some things more complicated in the case of tooltips, but if we use something else than tooltips to display that information we'll need to update when the backend signals a change anyway.

It's more complicated at two levels. In the implementation and in the usage ;)

Sure.

Let's talk about implementation first.

I need to go up the tree (of tasks) until I get to the project. Right now I do that with the full collection cache at hand, no problem.
IIUC, the live query mechanism will call my predicate with one item at a time, and I get to say "yes, keep this one".

Depends on the query part. It doesn't have to list the whole collection, it could just fetch the single item + ancestors and then return a list containing just the top most ancestor. Your predicate could then just return true if said parent was indeed a project. That fetch should not be expensive since in the current design it'll go through the cache anyway.

But that can't work if the predicate is called for the project before it's called for an intermediate parent task. I won't be able to say "yes this is my project" until I get the intermediate task which is the missing link to my child task.
Unless I'm missing something, I'd say the current framework for live queries isn't adapted to those needs.

I think it's because you're limiting yourself in the fetch part of the query, but that could be anything as long as it returns a list of items in the end.

Still in what I propose I'm not totally clear on change notifications... if an intermediate parent change project, there's currently nothing which would signal a change of project in the child. Note it's a problem already present in the current patch AFAICT.

I could of course still use m_cache->items(item.parentCollection()) in the predicate but that's crazy, right? There's no point in looking in ALL items every time the predicate is called with ONE item, this would amount to doing N times what can be done a single time...

It seems to me that we need a live query that calls (just once, not once per item) a method (one that returns a Project::Ptr, not a bool) whenever the collection has changed.
Using the cache, that method can right away return the project (if found).

That'd be an alternative indeed, maybe a better one even. Requires more work obviously.

It's an excellent start though! Looking forward to it, since we also have the findContexts for tasks it'll "just" be about channeling that information in the various models. :-)

When you say "we also have", do you mean this?

TaskQueries::ContextResult::Ptr TaskQueries::findContexts(Domain::Task::Ptr task) const
 {
     qFatal("Not implemented yet");
     Q_UNUSED(task);
     return ContextResult::Ptr();
 }

That's an interesting concept of "having" :-)

Damn, dunno why I was sure the implementation was already done... :-/

In D14591#304636, @ervin wrote:

Depends on the query part. It doesn't have to list the whole collection, it could just fetch the single item + ancestors and then return a list containing just the top most ancestor. Your predicate could then just return true if said parent was indeed a project. That fetch should not be expensive since in the current design it'll go through the cache anyway.

Ah, I see what you mean. But I'm hitting a new issue, trying to implement this.
There is no clean way to convert a task to a project. I mean, your description above relies on the fact that a project is a specific kind of task, but that's a kcalcore implementation detail that you tried hard to hide in the Domain classes and in AkonadiSerializer. So if my fetch returns tasks, even if my predicate filters for projects, the result of that query is still tasks.
... which the end user code (WorkdayPageModel's tooltip code, for now) then has to convert to Domain::Project somehow. I can probably get there by passing a serializer to that class, and then going task => item => project, but that seems horrible... Do we bite the bullet and add task<->project conversion methods to the serializer (without going via an unnecessary Akonadi::Item)? Or do I give up trying to make this a generic "findTopMostParentForTask" (as you described) and instead make it a findProjectForTask again, only working for projects?

Still in what I propose I'm not totally clear on change notifications... if an intermediate parent change project, there's currently nothing which would signal a change of project in the child. Note it's a problem already present in the current patch AFAICT.

This opens up an even wider question: can a task be in a project that actually belongs to a different akonadi collection? The code currently only searches within the same collection (I *think* I saw that somewhere already, so I took it as a constraint I could rely on). I guess that's ok, given that projects are indeed under collections in the tree? So that means "changing project" potentially means "moving to a different akonadi collection"? Subtasks included? Is there code to handle that?

If such a constraint exists at the akonadi::collection level, then change notifications should work, via "collection modified"... no?

It seems to me that we need a live query that calls (just once, not once per item) a method (one that returns a Project::Ptr, not a bool) whenever the collection has changed.
Using the cache, that method can right away return the project (if found).

That'd be an alternative indeed, maybe a better one even. Requires more work obviously.

Yeah... I don't even see from which angle to attack that one...