LiveQuery usage with multiple primary conditions

[tusharnaresh]

I have a dexie db instance with the below schema

music: &id, *creators, type

An example of such data can be taken as:

{
id:<alphanumeric characters>,
creators:<Array of artiste names>,
type:<String>
}

The type property can be any of the following types : [ROCK, JAZZ, POP, COUNTRY, FOLK].
I want to write a liveQuery such that it is only triggered when the creator is Jackson and the type is either ROCK, JAZZ and POP.
The current query i am using is:

const musicObservable = liveQuery(function () {
    return db.music.where('creators').equals("Jackson").filter((musicData)=>{
        if(['ROCK','JAZZ','POP'].includes(musicData.type))
        {
            return true;
        }
        return false;
    }).toArray();

But this doesn't seem to work and the querier function seems to run on all updates to the db.

[dfahlander]

The liveQuery should only trigger when one of the creators is Jackson (but the filter of genre cannot be observed as it's a manual filter on top of the index based filter of creators).

What happens if you:

1. ...add a new entry where Jackson isn't among the creators?
2. ...update an entry where Jackson isn't among the creators?
3. ...delete an entry where Jackson isn't among the creators?

None of these operations should trigger the query. If it does, it's a bug. However, a Jackson entry of type: 'SOUL' would still trigger the query (not bug).

[tusharnaresh]

Thanks for the reply. What can be the most optimal way of listening to changes for a group of fields. Is there any other way of achieving this maybe without liveQuery?.

[dfahlander]

The same principle applies for how to pick the part of the filter that can be accomplished using index when querying, is also used for detecting updates. That means, to pick the criteria that is most narrowing in the where-clause and complement it with filter and the false positive updates shouldnt e an issue.

Multiple criterias can sometimes fit into a single compound index but in this case it can't because I've of the criterias is a multientry index and indexeddb does not support combining compound and multientry indexes.

Can you confirm if this seems to be a bug or not from my last response (1, 2 and 3)?

[tusharnaresh]

By the explanation provided, 1,2 and 3 don't seem to be a bug to me. But for my use case, this behaviour would lead to multiple redundant recomputations in cases where entries get updated with proper creator and improper types. I am trying to find any possible way to minimize these un necessary recomputations when entries with improper types get created, updated or deleted.