Conversation
Align migrations with cakephp/database where possible. I've introduced some soft deprecations for the properties that have different names in migrations currently. Longer term, I'd like the internal data objects to be aligned and the compatibility shim is only used when constructing columns from arrays.
| [SqliteAdapter::PHINX_TYPE_MACADDR, false], | ||
| [SqliteAdapter::PHINX_TYPE_POINT, false], | ||
| [SqliteAdapter::PHINX_TYPE_POLYGON, false], | ||
| [Literal::from('someType'), true], |
There was a problem hiding this comment.
This is the one breaking change that was made for columns. I don't think this will be problematic, but I've been wrong in the past many times. Supporting this will require more shimming to make Literal compatible with types in cakephp/database, and will make Cake\Database\Schema\Column::$type into a union which splashes all over the internals of the ORM and database package in breaking ways.
Another option could be to handle the wider type in the constructor, and setType(), and downcast to a string there.
There was a problem hiding this comment.
I'd also drop this for now and revisit this later when someone runs into this problem in a real usecase.
Currently, we are just speculating if this feature is actually needed by users or not.
Align migrations with cakephp/database where possible. I've introduced some soft deprecations for the properties that have different names in migrations currently. Longer term, I'd like the internal data objects to be aligned and the compatibility shim is only used when constructing columns from arrays.