Implement computed fields as a relation #6032

New Issue

admin · 2026-01-22T15:25:06+01:00

admin commented

2026-01-22 15:25:06 +01:00

Originally created by @javi-p-nt on GitHub (Aug 8, 2018).

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

Implement computed fields as a relation:

As documented aggregated could only be fetched thru DQL, being explicitly requested, or being used thru model domain, having in both cases an overhead.

If these are implemented thru a new kind of relation OneToScalar, to give it a name, could be fetched lazily, being a major performance.

For example, a User is related with Transactions, and we only want to get the SUM(amount) of his transactions as balance. There's no need to make the heavyweight join on users fetching but on a one-to-one basis using lazy mechanisms implemented already on relations.

Originally created by @javi-p-nt on GitHub (Aug 8, 2018). ### Feature Request | Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | no #### Summary Implement computed fields as a relation: As [documented](https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/aggregate-fields.html#aggregate-fields) aggregated could only be fetched thru DQL, being explicitly requested, or being used thru model domain, having in both cases an overhead. If these are implemented thru a new kind of relation OneToScalar, to give it a name, could be fetched lazily, being a major performance. For example, a **User** is related with **Transactions**, and we only want to get the **SUM(amount)** of his transactions as balance. There's no need to make the heavyweight join on users fetching but on a one-to-one basis using lazy mechanisms implemented already on relations.

admin closed this issue

2026-01-22 15:25:06 +01:00

admin commented

2026-01-22 15:25:07 +01:00

@Ocramius commented on GitHub (Aug 9, 2018):

Can you make a code snippet of what you are imagining here? At first glance, this looks like a better fit for SQL and PostgreSQL materialized views rather than ORM mapping.

Remember that the ORM always considers in-memory state to be synchronised with the DB, so we don't plan to have any read-only fields anytime soon, because it breaks such a basic invariant.

@Ocramius commented on GitHub (Aug 9, 2018): Can you make a code snippet of what you are imagining here? At first glance, this looks like a better fit for SQL and PostgreSQL materialized views rather than ORM mapping. Remember that the ORM always considers in-memory state to be synchronised with the DB, so we don't plan to have any read-only fields anytime soon, because it breaks such a basic invariant.

admin commented

2026-01-22 15:25:08 +01:00

@javi-p-nt commented on GitHub (Aug 13, 2018):

Sorry being late, and thanks for the answer.

Yes, I thought using, views to circumvent the issue, but sadly, materialized views are dauntinly complex to achieve with MySql, and simple views are limited to being editable if do not have any COUNT, MAX, SUM, etc, so cannot be mapped directly to an entity, to be used as regular fields.

It's a pity that Doctrine won't support read only fields as others ORMs do.

Anyways, I've ended using a Lifeycle listener to populate the computed fields on demand, previously removing them from the mapping of the entity. Collaterally this method expands the architecture to allow caching ways for the computed fields.

Thanks again.

@javi-p-nt commented on GitHub (Aug 13, 2018): Sorry being late, and thanks for the answer. Yes, I thought using, views to circumvent the issue, but sadly, [materialized views](http://www.fromdual.com/mysql-materialized-views) are dauntinly complex to achieve with MySql, and simple views are limited to being editable if do not have any COUNT, MAX, SUM, etc, so cannot be mapped directly to an entity, to be used as regular fields. It's a pity that Doctrine won't support read only fields as others ORMs do. Anyways, I've ended using a Lifeycle listener to populate the computed fields on demand, previously removing them from the mapping of the entity. Collaterally this method expands the architecture to allow caching ways for the computed fields. Thanks again.

admin referenced this issue

2026-01-22 16:08:05 +01:00

[PR #7673] Add support for SequenceGenerator in strategy IDENTITY #10596

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6032