Added the MariaDB connections and verified and passed all auto tests.
There was not too much to fix. The TLS connections are still not
enabled.
- fixed upsert
- fixed tests
- enhanced upsert tests
- refactored tst_mysql_qdatetime to be able test both, the MySQL and
also MariaDB database connections
- added a few new MariaDB related tests
Changed from the 'schema' configuration option to the 'search_path',
the 'schema' config. option was dropped and currently throws exception
with a suggestion to use the 'search_path' instead.
The new 'search_path' config. option can be the QString or QStringList
and also supports to set an empty search_path using '' or empty QString
or QStringList.
This search_path config. option is correctly parsed and quoted.
Setting the search_path is initiated from the PostgresConnector
right after the database connection is established.
The PostgresSchemaBuilder is actively using the search_path during
practically all method calls (dropAllTables(), getColumnListing(),
hasTable(), ...). If the search_path is not defined then it queries
the database for the real search_path because the search_path can be
changed anytime and the search_path configuration option value can be
incorrect (out of sync).
It also works correctly with the empty search_path, in this case a fully
qualified table names are required. If the table name is not fully
qualified then the SearchPathEmptyError exception is thrown.
And it also works correctly with the "$user" PostgreSQL's variable, this
variable is resolved to the config["username"] during obtaining
the search_path from the database.
In the pretend mode it behaves little different, if pretending then
the 'search_path' is obtained from the connection configuration and
if the 'search_path' is not defined in the config. the 'public' will
be used as the default.
- added many new unit and functional tests which are testing all the
above described scenarios
- added new functional test case tst_PostgreSQL_SchemaBuilder_f
- added new functional test case tst_SchemaBuilder
- added new tests for dropAllTable(), dropAllViews(), hasTable(),
getColumnListing(), createDatabase(), dropDatabaseIfExists()
for ALL supported databases
- added new search_path constant
- renamed env. variable to DB_PGSQL_SEARCHPATH (from DB_PGSQL_SCHEMA)
- added new search_path and dont_drop configuration validations to
check correct type (QString or QStringList)
- added new 'schema' config. option validation
- added new exception SearchPathEmptyError
- started the TinyUtils::Databases refactor
Fixed buggy behavior of QDateTime values during SELECT, INSERT, and
UPDATE queries for all supported QtSql drivers. Behavior is fixed if
querying the database using Orm::QueryBuilder or TinyBuilder/Model.
Can't be fixed if using raw queries using the QSqlQuery because I don't
have any control over this code.
Every QtSql driver behaves differently in how it works with
the QDateTime and datetime-related database types. It doesn't have only
one problem, it has various kinds of problems, eg. it returns all
QDateTime objects in the local time zone. All issues are summarized
in NOTES.TXT under "QDateTime and database date/time types:"
section.
This buggy behavior can be fixed or corrected using a new "qt_timezone"
database connection configuration option. It accepts the time zone value
in various formats (QTimeZone, Qt::TimeSpec, int number as an offset
from UTC, QString eg. +02:00, Europe/Prague or Orm::QtTimeZoneConfig).
This "qt_timezone" value affects how the QueryBuilder and TinyBuilder
send and receives datetime-related types to/from database. It should be
set to the same time zone value as the "timezone" connection
configuration option.
During the INSERT and UPDATE statements, it CONVERTS QDateTime's
time zone to the qt_timezone value before the statement is sent
to the database.
And during the SELECT statements it SETS QDateTime's time zone value
after the values are obtained from the database.
So if you set the "timezone" to UTC and "qt_timezone" to eg. Qt::UTC or
QTimeZone::utc(), then QDateTime values will have set the correct
time zone, in this case, the time zone will be UTC.
For the SQLite database was also added the "return_qdatetime" connection
configuration option which default value is true. By default,
the QSQLITE driver returns datetime values as QString.
The "return_qdatetime" controls this behavior and if is set to true then
the QDateTime will be returned instead.
TinyORM QueryBuilder returns the Orm::SqlQuery instead of QSqlQuery
from methods for which the QDateTime's time zone should be corrected.
That are eg. the select(), selectOne(), unprepared(), or chunk(),
chunkById(), each(), eachById(), ...
Orm::SqlQuery is a simple wrapper around the QSqlQuery whose
responsibility is only to fix a QDateTime's time zone.
Also unified the QDate behavior across all QtSql drivers.
- added a new migration for the datetime table for testing QDateTime
and datetime-related database types
- added new Datetime model
- added functional tests for testing datetime-related queries
- testing QDateTime for all supported drivers
- testing with different time zones, UTC, +02:00
- testing QDate for all supported drivers
- added two new connection configuration options "qt_timezone" and
"return_qdatetime" which is for the SQLite database only
- added returnQDateTime()/setReturnQDateTime() getter/setter
to the SQLiteConnection class
- added getQtTimeZone()/setQtTimeZone()/isConvertingTimeZone()
to the DatabaseConnection class
- tests, fixed all QDateTime instances, changed time zone to UTC, so
auto tests are now UTC, they force also MySQL and PostgreSQL server
time zone session variable to UTC
Others:
- StringUtils moved from orm/tiny/utils/ to the orm/utils/ folder
to the ::Orm::Utils namespace
- enhanced all database connection constructors, used rvalue references
- added delegated DatabaseConnection() constructor
for SQLiteConnection() because of m_returnQDateTime
The MySQL >=8.0.19 supports aliases in the VALUES and SET clauses
of INSERT INTO ... ON DUPLICATE KEY UPDATE statement for the row to be
inserted and its columns. It also generates warning from >=8.0.20 if
an old style used.
This enhancement detects the MySQL version and on the base of it uses
alias during the upsert call.
Also a user can override the version through the MySQL database
configuration. It helps to save/avoid one database query
(select version()) during the upsert method call or during connecting
to the MySQL database (version is needed if strict mode is enabled).
- added unit and functional tests
- updated number of unit tests to 1402
- updated upsert docs
- added ConfigUtils to avoid duplicates
Others:
- added the version database configuration everywhere
- docs added few lines about MySQL version configuration option
- docs updated database configurations, added a new missing options
Primary fixed paths CMAKE_SOURCE_DIR, PROJECT_SOURCE_DIR,
CMAKE_BINARY_DIR and similar.
An user can use the following code in the CMakeLists.txt file to
fetch and configure the TinyORM project from GitHub:
FetchContent_Declare(TinyORM
GIT_REPOSITORY https://github.com/silverqx/TinyORM.git
GIT_TAG origin/main
)
# Here you can configure TinyORM CMake options
set(TOM_EXAMPLE ON)
FetchContent_MakeAvailable(TinyORM)
Be able to build with clang-cl with MSVC 2019/2022 but only with
inline constants.
- supported by both CMake and qmake 🎉
- updated docs support compilers
qmake specific:
- enhanced and fixed tiny_toolchain_requirement
- added clang-cl min. required version to tiny_toolchain_requirement
- enhanced winconf.pri
- updated conf.pri.examples
- added a new feature file the tiny_system_headers.prf, it unifies
tagging system headers
cmake specific:
- also added clang-cl min. required version as minReqClangClVersion
- for clang-cl set the INLINE_CONSTANTS to ON and don't show this
CMake option
The db:seed command invokes the root seeder DatabaseSeeder which can
invoke another seeders using the call() related methods. The root seeder
can be set by the --class command-line option and also by the --seeder
cmd. line option on some other commands like migrate:fresh/refresh.
Seeders can be passed to the Tom application in the similar way like the
migrations using the TomApplication::seeders<>() method or through the
constructor.
Arguments can be passed to the call<>() method, then the seeders run()
method will not be called using the virtual dispatch but using the type
traits. Of course the arguments passed to the call<>() method has to
match with the run() method parameters.
Others:
- unified usingConnection() across all commands, this functionality was
extracted to own class, previous it was a part of the Migrator class,
so now every command even if it doesn't use Migrator can call
the usingConnection() and it correctly sets a default connection and
SQL queries debugging on the base of the -vvv command-line argument
- a default database connection is now required, if not set then
the exception will be thrown
- added example seeders to the Tom application
Migration classes can be named in two formats, CamelCase without the
datetime prefix and snake_case with the datetime prefix.
If the CamelCase name is used then the T_MIGRATION macro has to be
also used in the migration class.
- also added a new validations of the migration class names
User can provide a custom migrations path for the make:migration
command.
Default path is at database/migrations relative to the tom example
executable.
This allows to use the tom example as a real migration application and
the user doesn't have to create his own migration project.
Using:
- TomApplication::migrationsPath()
- TINYTOM_MIGRATIONS_PATH preprocessor macro, will be stringified
- TOM_MIGRATIONS_PATH CMake PATH option
