DB Information Schema - COLUMNS #318
Conversation
- covered in more details COLUMNS and TABLES interfaces - removed other interfaces from the proposal - added profiles
- updated different column classes
|
@akaplya can you review it pls it looks good to me |
|
Kann be merged told me @akaplya |
| ``` | ||
|
|
||
| ``` | ||
| class InformationSchema\Table\VarBitColumn extends Column |
There was a problem hiding this comment.
Do we need to introduce types that are not used by application currently? We will have to make sure that these types support across different databases engines.
There was a problem hiding this comment.
@melnikovi No they are not necessarily needed, I just added them for the sake of being complete. Technically both bit and bit varying have been dropped as of SQL-2003, so we can stimply ommit these.
There was a problem hiding this comment.
Ok, I removed the classes for bit and bit varying from the proposal.
| public function getDefaultValue(): ?float {} | ||
| } | ||
| ``` | ||
| Note that ANSI-SQL defines the exact numerical data types `DECIMAL` and `NUMERIC` as being equivalent. MySQL / MariaDB |
There was a problem hiding this comment.
I would try to make columns types generic and delegate responsibility of mapping them to particular database engine to management classes.
There was a problem hiding this comment.
@melnikovi Agreed. Should I add a complete overhaul of the DBAL in this proposal?
There was a problem hiding this comment.
It's ok to not include this in the design. The idea is that providers will map database specific types to generic types in application.
There was a problem hiding this comment.
I added a comment in the section "Providers" stating what we have discussed.
| /** | ||
| * Returns the character set name. | ||
| * | ||
| * Note that not all RDBMS support this, returning `null` indicates whether this is supported. |
There was a problem hiding this comment.
We can't make type like this. We want to be able to swap database engine and have everything work, so API that we provide should be compatible with all databases engines.
There was a problem hiding this comment.
@melnikovi Do you suggest to drop all non-ANSI-SQL features from column classes or do you have something else in mind?
There was a problem hiding this comment.
Yes, let's limit column types to currently used (can check declarative schema to see what is used).
There was a problem hiding this comment.
All non-ANSI-SQL features were removed from column classes.
|
Feedback after review with @akaplya, @buskamuza and @fascinosum
Also need to consider
|
|
@melnikovi in PHP we do not have enum type to archive this we need to use a library like https://github.com/spatie/enum or https://docs.spatie.be/enum/v2/introduction/. |
|
@larsroettig I was referring to this https://www.php.net/manual/en/class.splenum.php. |
|
@melnikovi I have a couple of questions about you considerations:
Fine with me, but bear in mind that these vary from RDBMS to RDBMS, thus those enums would have to be located in the DBAL.
Can you elaborate what you mean exactly? Imho the return type of
What do you propose? |
I added that to the proposal. We may not be able to use
I removed them as requested
That was already done, there are type specific classes for all ANSI-SQl variants of |
|
Open questions will be finalized in subsequent proposals. |
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.