It started with observing that the new PradoUnit helper class had an error in it. That exposed many database error that were incorrectly being suppressed. This is a big bug in the Database testing and integration for sqlite, pgsql, and mysql.
we need integration unit tests of TDbCommand for each database. This is natural given that we have a test directory for each DB now rather than just a file.
While working on the IBM DB2 and firebird support (before), I saw how dispersed the driver support was. Moving forward, it should be centralized.
We don't need to support Mongo-db but we should be extensible enough to be able to support it. (I have a composer plugin being prepared for this).
We should probably support ODBC at some point. I'm working on making adding support easier. Not in this issue/pr.
The capabilities of the Drivers expanded to support all the features and distinctions of the common PDO databases, naturally. This changes TDBConnection, TDbMetaData, TDbTransaction, TActiveRecordAction, and TScaffoldInputBase,
The Extensibility of Data.* to other database systems should be part of Prado. So now we have many interface classes in Data, and Data.Common. These interfaces are part of the TDbDriverCapabilities and validating classes coming from a plugin.
as an aside, one analysis of PRADO Data pointed out that INSERT OR IGNORE and UPSERT are missing features, which I started upon the last Database update PR. That's what led me to see the bug in PradoUnit. These features were relatively easy to include, but would update the new Data-Common interfaces too.
Some modules may have their own driver string names, and centralizing the PDO driver names is important, TDbDriverCapabilities uses driver names extensively. They are prone to mis-spelling. Which thus necessitates a TDbDriver class. This touched several DB classes.
This led to seeing that several places are trying to support driver mysqli and mssql which are not actually PDO drivers. mysqli and mssql are PHP extensions that add their own methods to PHP rather than extending PDO.
The way charset works with DSN charset was really weak. charset property should key from dsn charset when it's present.
the connection itself could have commit/rollback for transaction based databases (Firebird) or when auto commit is off.
TDbTransaction should be able to restart a transaction after completion. adding "serial transaction".
There was a massive rabbit hole nothing-burger regarding PHP PDO and a faulty unit test that the AI couldn't comprehend. go figure that one.
this updates the phpdoc on many classes, some of the phpdoc was just atrociously lacking.
It adds/changes 117 files. It's at: https://github.com/belisoful/prado/tree/db-modern-exec
@ctrlaltca I'm not sure how to split this up into smaller pieces that make sense to you and keep the PRs straight forward.
It started with observing that the new PradoUnit helper class had an error in it. That exposed many database error that were incorrectly being suppressed. This is a big bug in the Database testing and integration for sqlite, pgsql, and mysql.
we need integration unit tests of TDbCommand for each database. This is natural given that we have a test directory for each DB now rather than just a file.
While working on the IBM DB2 and firebird support (before), I saw how dispersed the driver support was. Moving forward, it should be centralized.
We don't need to support Mongo-db but we should be extensible enough to be able to support it. (I have a composer plugin being prepared for this).
We should probably support ODBC at some point. I'm working on making adding support easier. Not in this issue/pr.
The capabilities of the Drivers expanded to support all the features and distinctions of the common PDO databases, naturally. This changes TDBConnection, TDbMetaData, TDbTransaction, TActiveRecordAction, and TScaffoldInputBase,
The Extensibility of Data.* to other database systems should be part of Prado. So now we have many interface classes in Data, and Data.Common. These interfaces are part of the TDbDriverCapabilities and validating classes coming from a plugin.
as an aside, one analysis of PRADO Data pointed out that
INSERT OR IGNOREandUPSERTare missing features, which I started upon the last Database update PR. That's what led me to see the bug in PradoUnit. These features were relatively easy to include, but would update the new Data-Common interfaces too.Some modules may have their own driver string names, and centralizing the PDO driver names is important, TDbDriverCapabilities uses driver names extensively. They are prone to mis-spelling. Which thus necessitates a TDbDriver class. This touched several DB classes.
This led to seeing that several places are trying to support driver
mysqliandmssqlwhich are not actually PDO drivers. mysqli and mssql are PHP extensions that add their own methods to PHP rather than extending PDO.The way charset works with DSN charset was really weak. charset property should key from dsn charset when it's present.
the connection itself could have commit/rollback for transaction based databases (Firebird) or when auto commit is off.
TDbTransaction should be able to restart a transaction after completion. adding "serial transaction".
There was a massive rabbit hole nothing-burger regarding PHP PDO and a faulty unit test that the AI couldn't comprehend. go figure that one.
this updates the phpdoc on many classes, some of the phpdoc was just atrociously lacking.
It adds/changes 117 files. It's at: https://github.com/belisoful/prado/tree/db-modern-exec
@ctrlaltca I'm not sure how to split this up into smaller pieces that make sense to you and keep the PRs straight forward.