Readonly column property for generated/virtual columns

[Hikariii]

MySQL and MariaDB both support virtual/computed/generated columns.
This is a column in a table that has its value automatically calculated using a deterministic expression, in particular from the values of other fields in the table.
These columns are queried like any other column, but its values cannot be inserted or updated.
To use these columns in entities and DQL, Doctrine must find a way to define them, but not include them in updates and inserts. This PR accomplishes just that.

More info on these columns:

• MariaDB: https://mariadb.com/kb/en/mariadb/virtual-computed-columns/
• Mysql: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

[Hikariii]

Fixes #4427

[Hikariii]

As more people are moving towards mysql 5.7 this will become more of an issue.
I suggest a review of this feature to start support for generated columns and enable developers going forward with their stack.

[Ocramius]

This seems to support an edge-case scenario that is DB-specific. Any reason why you can't simply skip mapping those fields?

In addition to that, userland object implementations may still overwrite those field values, leading to out-of-sync db and object model. In addition to that a full entity refresh should be forced if one of those fields is computed.

I think the resolution for this issue is as simple as "don't map it", which will lead the ORM to completely ignore the field anyway.

Tossing in my 👎 for now, but I hope you understand why this is my opinion on the feature.

[guilhermeblanco]

I'm planning to remove "readOnly" support in ORM 3.0 and implement a decoupled support through: "insertable" and "updatable" at both Entity and Column level.

Adding something that will be immediately deprecated after is a no-go to me.

[Majkl578]

Closing this as per @guilhermeblanco's comment.

[sinelnikovd]

Is there any solution of the problem? I have some issues with a column generated from the “Sequence” in my database (Postgresql)

[beberlei]

A similar solution based on this PR, but not with readOnly instead using updateable and isUpdateable targeting the 2.* branch would be merged by me. The behavior for updateable would be:

(Optional) Whether the column is included in SQL UPDATE statements generated by the persistence provider.

Additional conditions: Should throw exception for UPDATE statements attempting to update this field/column.

Could be combined directly by adding insertable, which is the same for including the column in insert statements or not.

One question would be, if an update or insert is done, then the persister must probably fetch the value of the columns from the database, because they are virtual and might be updated. Example: Auto Increment non ID columns, or timestamps updated on write, trigger based columns.

[liviucmg]

@beberlei I recently stumbled upon this problem and I can confirm that @Hikariii's PR works on the 2.8.2 branch. I can try and prepare a PR for the latest 2.* that has updateable, isUpdateable, insertable, and isInsertable. Just want to know if you would consider merging it?

[man-htsts]

A similar solution based on this PR, but not with readOnly instead using updateable and isUpdateable targeting the 2.* branch would be merged by me. The behavior for updateable would be:

(Optional) Whether the column is included in SQL UPDATE statements generated by the persistence provider.

Additional conditions: Should throw exception for UPDATE statements attempting to update this field/column.

Could be combined directly by adding insertable, which is the same for including the column in insert statements or not.

One question would be, if an update or insert is done, then the persister must probably fetch the value of the columns from the database, because they are virtual and might be updated. Example: Auto Increment non ID columns, or timestamps updated on write, trigger based columns.

Where can i find the similar solution that you was talking to merge?