You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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
Database
andConnection
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
andConnection
(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.
The text was updated successfully, but these errors were encountered: