DB Information Schema - COLUMNS #306
Conversation
- covered in more details COLUMNS and TABLES interfaces - removed other interfaces from the proposal - added profiles
- updated different column classes
|
@buskamuza can we add a section about backward compatibly? This is planned for the 2.3.x branch correct? |
| public function getIsNullable(): bool {} | ||
| public function getExtra(): Extra {} | ||
| public function getComment() {} | ||
| public function getDefaultValue(): string {} |
|
|
||
| `\Magento\Framework\DB\Adapter\AdapterInterface` has methods like `describeTable` which return raw values from database engine. This is leaky interface. We should have interfaces that return normalized data and are compatible with all databases. Methods that don't return normalized data need to be deprecated on `\Magento\Framework\DB\Adapter\AdapterInterface`. | ||
|
|
||
| `engine` field in declarative schema need to be deprecated. |
There was a problem hiding this comment.
Removed. It's part of original document.
buskamuza
changed the title
|
Can we make |
| public function getIsNullable(): bool {} | ||
| public function getExtra(): Extra {} | ||
| public function getComment() {} | ||
| public function getDefaultValue(): ?string {} |
There was a problem hiding this comment.
Shouldn't this one be more generic and then strongly typed on the type specific implementations?
Examples:
\InformationSchema\Table\Column::getDefaultValue()\InformationSchema\Table\VarcharColumn::getDefaultValue(): ?string\InformationSchema\Table\IntColumn::getDefaultValue(): ?int\InformationSchema\Table\FloatColumn::getDefaultValue(): ?float\InformationSchema\Table\DateColumn(): ?string
There was a problem hiding this comment.
Should we remove table_name field? I also think that default_value might be better to move to specific types
| { | ||
| public function getSchema(): string {} | ||
| public function getName(): string {} | ||
| public function getEngine(): string {} |
There was a problem hiding this comment.
Propose to either to remove it or introduce enum for engine. I think we need to introduce enums for collation and charset. What is schema, definition of the table?
There was a problem hiding this comment.
I would not use an enum for the engine. Technically most RDBMS support having storage engines other than their default but this is mostly used in MySQL / MariaDB. Introducing an enum for engines could become a maintenance issue as MySQL / MariaDB evolve (e.g. as of MariaDB 10.4 the default storage engine is AriaDB which is an evolution of MyISAM).
Schema is (more or less) the database in which the table resides. SQL defines that a table resides in the schema of a catalog, hence the columns information_schema.tables.catalog and information_schema.tables.schema. MySQL / MariaDB do not support catalogs thus the schema reflects the database (as opposed to PostgreSQL supporting multiple schemas per catalog).
| ``` | ||
| class InformationSchema\Extra | ||
| { | ||
| public function getOnUpdate(): string {} |
There was a problem hiding this comment.
I think it might differ between databases, I would propose to introduce enums.
| ``` | ||
| class InformationSchema\Table\VarcharColumn extends Column | ||
| { | ||
| public const TYPE = 'VARCHAR'; |
There was a problem hiding this comment.
I would remove it from here because it differs between database engines.
|
|
||
| public function isUnsigned(): bool {} | ||
| public function getPadding(): int {} | ||
| public function getType(): IntEnum {} |
There was a problem hiding this comment.
Propose to have different types instead.
| The profiles are declared in `di.xml` or as a separate configuration, with the following structure: | ||
|
|
||
| ``` | ||
| information_schema_profiles: |
There was a problem hiding this comment.
Should it be databse_information_schema_profiles?
| ``` | ||
| class InformationSchema\Table | ||
| { | ||
| public function getSchema(): string {} |
There was a problem hiding this comment.
I suggest to remove it as it comes from connection and changing this field will not rename database.
|
Closing in favor of #318 |
Problem
This is a subset of #264 , covering only COLUMNS and TABLES interfaces.
Different RDBMS return Information Schema (metadata) information in different format. Magento framework should allow to switch between different implementations in order to support those different versions of DBs, as well as differences between versions.
Solution
Introduce granular interfaces, based in Information Schema standard (looking into MySQL and MariaDB definitions in this scope, links are in the document). Application can switch between different implementation based on the profile.