Introduce covariant types ino fa-db

[benedeki]

Background

Many core fa-db classes are type parametrized, using invariant types.

Feature

It might be needed for better flexibility to introduce covariants, for example in DBExecutor[E]

[salamonpavel]

In Scala, variance annotations (+T, -T) are used to express how types with a certain type parameter relate to each other when the type parameter is a subtype or supertype of another type. This is useful for collections and function types, among others.

However, when it comes to SQL queries modeled as Scala classes, variance doesn't make much sense. Here's why:

1. Queries are not collections: Variance is often used with collections, where it's useful to be able to treat a List[Dog] as a List[Animal] if Dog is a subtype of Animal. But a SQL query is not a collection. It's a description of an operation to be performed on the database.

2. Queries don't have subtypes: In a SQL query modeled as a Scala class, the type parameter typically represents the type of the data returned by the query. But one query doesn't subtype another query. Each query is a distinct operation with its own return type.

3. Queries are invariant in their result type: The result type of a query is fixed. If a query returns rows of type Dog, you can't use it as if it returned rows of type Animal or Poodle. You have to write a different query to get rows of a different type.

So, in the context of SQL queries modeled as Scala classes, variance annotations would not provide any benefit and could potentially lead to incorrect code if they were allowed.

[salamonpavel]

https://docs.scala-lang.org/tour/variances.html

[lsulak]

We had a talk about it and possibly this could be limited to be added into the apply functions in the za/co/absa/db/fadb/DBFunction.scala classes. To allow to:

• have more concrete type supplied into the apply function for the input type (I in code)
• have more abstract type returned from the apply function as the return type (R in code)