Right now, a number of queries will throw exception on cassandra. For instance, a query with an OR clause. Here's my idea for making this typesafe:
add a type parameter to LongevityContext and Repo for the back end. Those types already exist in longevity.config.BackEnd. We will probably need to pull this as a configuration var at the same time. If so, we probably want to move that class hierarchy too - perhaps into longevity.context? Or into a new longevity.backend package.
Create a type class OrSupport[_ <: BackEnd]. Give it a private[longevity] constructor so people can't create their own.
Create implicit OrSupport[MongoDB], etc., for the back ends that support or queries. Put them where they will be found by implicit search - probably in the OrSupport companion object would be best.
Add an implicit OrSupport[BE] argument for the "or" query methods - both in the query ADT and the query DSL.
Repeat for other query clauses that don't work on Cassandra.
Don't forget to delete the cassandra specific query exception classes
Right now, a number of queries will throw exception on cassandra. For instance, a query with an OR clause. Here's my idea for making this typesafe:
LongevityContext
andRepo
for the back end. Those types already exist inlongevity.config.BackEnd
. We will probably need to pull this as a configuration var at the same time. If so, we probably want to move that class hierarchy too - perhaps intolongevity.context
? Or into a newlongevity.backend
package.OrSupport[_ <: BackEnd]
. Give it aprivate[longevity]
constructor so people can't create their own.OrSupport[MongoDB]
, etc., for the back ends that support or queries. Put them where they will be found by implicit search - probably in theOrSupport
companion object would be best.OrSupport[BE]
argument for the "or" query methods - both in the query ADT and the query DSL.