Lukáš Stuchlík

Looking at the code and the example I found works (putting the fragments before query), I think what could work is: - extract the fragment definitions from the document (I...

Until it's implemented, you can somewhat workaround it by overriding the data provider and modifying the filter object (e.g. I had a situation where `effectiveTo` is often `null` but still...

The PR probably fixed only where it's in the NOT, OR or AND operators. In my case, `effectiveTo: null` still gets into https://github.com/panter/ra-data-prisma/blob/master/packages/dataprovider/src/buildWhere.ts#L109 and outputs ```ts effectiveTo: { equals: "1970-01-01T00:00:00.000Z"...

Once I have a bit more time I could potentially take a look at that, until then ```ts field: { equals: null } ``` fortunately works

Copying @emallson's thoughts from Discord: > - splitting SPELLS is good, progress on that is desireable > - we effectively never use the name/icon data from SPELLS except when debugging...

> Maybe I'm missing something, but I don't see how the __tag field would in your example push anyone to use the spell() functionality? That's what I thought too, maybe...

I mean, the problem with autocompletion with current `SPELLS` is mostly in the sheer size. If the amount of keys is reduced (which would be in any case where using...

Cool, I'd like to turn attention to the core modules once more - things like `SpellResourceCost`, `SpellUsable`, `StatTracker` etc. etc. If we ditch indexing by spellId (which I think we...

Yeah, most of the use cases in class analyzers are for arrays of spells. That could be refactored to be a `Spell[]` and while iterating you know you can access...

I think I didn't have any issues on Linux either (Manjaro if it makes any difference)