Add Column from migrations #18748
Add Column from migrations #18748
Conversation
Having a column model in cakephp/database will let us move away from the array metadata in the future, and will let us remove more code from migrations down the road as well. This new model needs to be connected to `TableSchema` next.
This 'works' but I think there are still a few rough edges with how attributes like autoIncrement are handled.
While migrations/phinx used signed, cakephp went with unsigned. Align with the framework. Migrations can provide shim methods.
No need to create a new set of names. Migrations can offer a wrapper with compatibility.
In the future, we could deprecate autoIncrement and use identity instead.
There was a problem hiding this comment.
Pull Request Overview
Part of #18362: Introduces an object‐based API for schema metadata by adding a Column class and integrating it into existing schema tooling.
- Adds
TableSchema::column()to returnColumnobjects and updates tests to exercise it - Creates a full
ColumnTestsuite covering property setters and option mappings - Refactors Postgres identity SQL to use a
GENERATED_BY_DEFAULTconstant
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tests/TestCase/Database/Schema/TableSchemaTest.php | Added column() assertions for title, author_id, and amount columns |
| tests/TestCase/Database/Schema/MysqlSchemaDialectTest.php | Extended describeTable() tests with column() method integration |
| tests/TestCase/Database/Schema/ColumnTest.php | New comprehensive tests for the Column class |
| src/Database/Schema/TableSchema.php | Introduced column() method returning a Column object |
| src/Database/Schema/PostgresSchemaDialect.php | Switched hardcoded 'BY DEFAULT' to static::GENERATED_BY_DEFAULT |
Comments suppressed due to low confidence (5)
tests/TestCase/Database/Schema/TableSchemaTest.php:231
- The test only asserts the column type for 'title' but does not verify other default attributes (length, default, null, unsigned, comment). Consider adding assertions for these getters to improve coverage of the new column() API.
$column = $table->column('title');
tests/TestCase/Database/Schema/TableSchemaTest.php:269
- The test covers type, length, and precision but omits assertions for default, null, unsigned, and comment. Adding these checks will ensure complete coverage of the Column object's state.
$column = $table->column('amount');
src/Database/Schema/PostgresSchemaDialect.php:34
- [nitpick] PhpDoc for constants typically uses
@varrather than@const. Consider changing the tag to@var stringor adding a descriptive comment to align with project doc conventions.
* @const string
src/Database/Schema/TableSchema.php:394
- [nitpick] It may help to clarify in this docblock how
column()differs from the existinggetColumn()method to avoid confusion between the array-based and object-based APIs.
* Get a column object for a given column name.
src/Database/Schema/TableSchema.php:401
- The method return type references Column but no import for
Cake\Database\Schema\Columnwas added in this diff. Ensure you haveuse Cake\Database\Schema\Column;at the top of the file to avoid a runtime error.
public function column(string $name): Column
src/Database/Schema/Column.php
Outdated
| * @throws \RuntimeException | ||
| * @return $this | ||
| */ | ||
| public function setOptions(array $options) |
There was a problem hiding this comment.
Can we name this setAttributes()? "columns attributes" sounds better to me than "column options".
| * @param string $name Name | ||
| * @return $this | ||
| */ | ||
| public function setName(string $name) |
There was a problem hiding this comment.
Still having to use these single line boilerplate get/set methods make me sad :(
There was a problem hiding this comment.
Yeah :( we could switch to property hooks for 6.x though.
There was a problem hiding this comment.
Every per attribute getter/setter simply reads/writes the property. Since they are typed we don't need any additional processing, so can't we have them a just public properties?
In most use cases all attributes would be set at object construction time itself, so don't see much need for individual setters.
There was a problem hiding this comment.
Having getter methods at least would make sense if we had an interface.
There was a problem hiding this comment.
In most use cases all attributes would be set at object construction time itself, so don't see much need for individual setters.
Currently there isn't a way to set attributes via the constructor. I will add one.
Since they are typed we don't need any additional processing, so can't we have them a just public properties?
I'm hesitant to add public properties, as we spent a bunch of time removing them all back in the day.
There was a problem hiding this comment.
I'm hesitant to add public properties, as we spent a bunch of time removing them all back in the day.
Properties couldn't be typed backed then but okay.
There was a problem hiding this comment.
That's fair. PHP has changed since then, and Column (and also Index and ForeignKey in the future) are mostly simple PHP objects. I'll check to see if there are any attributes that would require more complex logic that couldn't be handled with public properties. I'd like to not have a mixed API with a blend of public properties and setter methods.
There was a problem hiding this comment.
I took a look at the Index and ForeignKey classes in migrations. While Index could work with typed public properties. The ForeignKey class has some logic to constrain & validate deferred and update/delete action values. We wouldn't be able to provide those checks with public properties.
I think we are stuck with methods for now, at least until property hooks become available.
Part of #18362. Import the
Columnobject from migrations into cakephp. I think having an object based API for schema metadata would be a better API in the future. HavingColumnwill help simplify migrations further (minus some deprecations in migrations).