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
Renamed cmake option and macro from the TINY/TOM_MIGRATIONS_PATH to the
TINY/TOM_MIGRATIONS_DIR.
- updated documentation
- extracted init. code for the TINYTOM_MIGRATIONS_DIR to the own cmake
macro
Enhanced migration name detection for the make:migration, practically
all the possible combinations are allowed and handled correctly 👀😎.
Now is possible to pass the full migration name with the datetime prefix
and with the filename extension. All possible combinations are
supported.
Summarize, so an user can pass:
- classname that will be converted to the studly case
- filename without the datetime prefix (with or w/o extension)
- filename with the datetime prefix (with or w/o extension)
make:migration command is able to guess the table name and creation
status from the passed migration name on the command line.
If the migration name begins with the create_ string then the create
migration stub will be used.
If the migration name contains the (to|from|in)_ pattern then the update
migration stub will be used.
In all other cases an empty migration stub will be used.
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
- different render format for options with values --env[=ENV]
- printing a default value part after the description
- added some validations for option names, especially validate the size
- fixed default value name in all commands, it should be upper
Created own tomconstants for the Tom namespace (folder tom/) and used
them everywhere.
Others:
- removed Q_GLOBAL_STATIC_WITH_ARGS() in migrationcreator.cpp and used
getter with the local static const
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
Only partial names no matter of case can be passed, eg. mi:st for
the migrate:status, or m for the migrate command.
If the passed name is ambiguous then the error wall with all ambiguous
commands or namespaces is displayed, ambiguous commands also contain
a description.
Following positional arguments support guessing:
- main command name at 0 position
- command name passed to the help command
- namespace name passed to the list command
The vt100 processing is not enabled on the MSYS2 ucrt64 by default so
enable it explicitly.
- also moved terminal initialization code to the Tom::Terminal class
silverqx