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
base: master
from

Conversation

Projects
None yet
4 participants
@Hikariii
Copy link

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

This comment has been minimized.

Copy link
Author

Hikariii commented Mar 21, 2016

Fixes #4427

@Hikariii Hikariii closed this Mar 21, 2016

@Hikariii Hikariii reopened this Mar 21, 2016

@Hikariii

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

Majkl578 commented Dec 8, 2017

Closing this as per @guilhermeblanco's comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.