the database model and query-builders operate entirely in the abstract with no dependency on any physical database connection, which is great, as it enables you to write (and unit-test) complex query-builders independently of any database connection.
In practice, we haven't seen anybody doing this.
Writing unit-tests for query-builders, in practice, is a somewhat redundant exercise, as a passing unit-test does not guarantee an SQL query that actually executes, or does what you intended.
In practice, everyone has been exclusively writing integration tests against real databases - these provide the same (or better) coverage than a unit-test, and nobody wants to maintain an extra unit-test with different assertions testing practically all of the same details.
In addition, the Database and Connection implementations do have co-dependencies, which aren't apparent and can't really be modeled at the moment.
Therefore, let's consider folding the Database and Connection (and possibly Driver) into a single unit with a single, common interface - thus simplifying the overall architecture and dependency management in our client code.
This would be a major breaking change - however, as it affects bootstrapping and dependency management only, it is not a change with a very high cost in terms of upgrading client code.
We should carefully scrutinize this decision - is there any reasonable argument for keeping things the way they are? Are we losing something if we change this?
Needs further discussion and/or prototyping with integration against a real-world project.
The documentation states:
In practice, we haven't seen anybody doing this.
Writing unit-tests for query-builders, in practice, is a somewhat redundant exercise, as a passing unit-test does not guarantee an SQL query that actually executes, or does what you intended.
In practice, everyone has been exclusively writing integration tests against real databases - these provide the same (or better) coverage than a unit-test, and nobody wants to maintain an extra unit-test with different assertions testing practically all of the same details.
In addition, the
DatabaseandConnectionimplementations do have co-dependencies, which aren't apparent and can't really be modeled at the moment.Therefore, let's consider folding the
DatabaseandConnection(and possiblyDriver) into a single unit with a single, common interface - thus simplifying the overall architecture and dependency management in our client code.This would be a major breaking change - however, as it affects bootstrapping and dependency management only, it is not a change with a very high cost in terms of upgrading client code.
We should carefully scrutinize this decision - is there any reasonable argument for keeping things the way they are? Are we losing something if we change this?
Needs further discussion and/or prototyping with integration against a real-world project.