Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Readonly column property for generated/virtual columns #5728

Closed
wants to merge 3 commits into from

Conversation

@Hikariii
Copy link

@Hikariii Hikariii commented Mar 21, 2016

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:

@Hikariii
Copy link
Author

@Hikariii Hikariii commented Mar 21, 2016

Fixes #4427

@Hikariii
Copy link
Author

@Hikariii Hikariii commented Jun 15, 2016

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
Copy link
Member

@Ocramius Ocramius commented Jun 15, 2016

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
Copy link
Member

@guilhermeblanco guilhermeblanco commented Jun 15, 2016

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
Copy link
Contributor

@Majkl578 Majkl578 commented Dec 8, 2017

Closing this as per @guilhermeblanco's comment.

@sinelnikovd
Copy link

@sinelnikovd sinelnikovd commented Nov 19, 2020

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

@beberlei
Copy link
Member

@beberlei beberlei commented Nov 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants