opaque json mappping

[tpolecat]

This adds an opaque: Boolean = false argument to the constructors for mappings that are backed by CirceCursor. If this field if true then the underlying JSON is considered to be the final result and no attempt is made to hop into other mappings if another mapped type is encountered during traversal. The use case is a deep structure that appears twice as a return type in the schema, served in one place by a SQL mapping and in another place by a computed JSON mapping.

This also turns off BSP processing for non-JVM projects. I think this may have already been done on another branch.

[toddburnside]

I believe bsp was turned off a different way in #458

[tpolecat]

Cool I'll undo that.

[milessabin]

Can't this be achieved with a PrefixMapping?

[tpolecat]

Can't this be achieved with a PrefixMapping?

Yes, but you need a PrefixMapping for every type in the subtree, which in our particular case is a lot. You can also do this by overriding mkCursorForField in your Mapping to treat all CirceCursors this way (which is what we have done), so if this change isn't sensible we can fall back to that.

[milessabin]

Yes, but you need a PrefixMapping for every type in the subtree

That's bad, agreed. But maybe we can come up with a generalization of PrefixMapping which could do the job more straightforwardly? What is the condition that determines whether the circe cursor should be used? Could we express that as a more general predicate than a path prefix?

[tpolecat]

What is the condition that determines whether the circe cursor should be used?

In our case it's universal (if the parent is a circe cursor then the child should also be a circe cursor) but more generally if the path from the root is X/Y/Z then all children should be circe cursors. The solution I propose here marks this at the parent node X/Y/Z rather than marking it at all child nodes X/Y/Z/**/Q.

[milessabin]

See #461.

[milessabin]

Superseded by #565.