Proposal: partial objects, lazy load for field access

[TriAnMan]

The documentation tells that it is not possible in PHP:

In PHP though this is not possible, so there is no way to have "secure" partial objects in an ORM with transparent persistence.

But my opinion that it is possible to do through magic methods (__get and __set). However there still one problem: the syntax highlighting. This can be solved with a @property annotation, which is supported with all contemporary IDEs.

The ActiveRecord realization in Yii2 uses similar approach.

[Ocramius]

@TriAnMan this could kinda work with the #1241 PoC. We can't base everything on __get or __set, as consumers type-hint against specific domain interfaces.

The idea is to generate "partial proxies" that support hydration of single fields or groups of fields.

[DHager]

Instead of packing more complexity into an entity/PHP-object (by having lazy-loaded fields), what about taking the opposite approach? Give users a mechanism to map a single database row to multiple entities with non-overlapping field-responsibilities.

For example, suppose you're forced to deal with some legacy sales_record table has an unwieldy pdf_data column. What if you could map that to two in-memory entities, SalesPdf (with just one property) and SalesRecord (with all the other properties and a one-to-one association to SalesPdf.)

This would obviously complicate things in terms of identity-mapping and how commits have to occur, but it would bypass a whole lot of potential PHP-land problems with proxies and inheritance and interfaces.

[Ocramius]

Instead of packing more complexity into an entity/PHP-object (by having lazy-loaded fields),

We're actually simplifying the entire proxy stuff there

what about taking the opposite approach? Give users a mechanism to map a single database row to multiple entities with non-overlapping field-responsibilities.

That is also in the works. @guilhermeblanco was looking into a way to define hydration manually via M:N field mappings.

This would obviously complicate things in terms of identity-mapping and how commits have to occur, but it would bypass a whole lot of potential PHP-land problems with proxies and inheritance and interfaces.

It wouldn't complicate anything if hydration/extraction (and associated testing) are delegated to the user for edge-cases.

We're very far from that tho, and generating proxies for partial objects is actually already available.

[tacman]

Partial objects have been deprecated/removed, some alternative solutions can be found here: https://github.com/doctrine/orm/issues/8471