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

Proposal: partial objects, lazy load for field access #5659

Open
TriAnMan opened this issue Feb 9, 2016 · 4 comments
Open

Proposal: partial objects, lazy load for field access #5659

TriAnMan opened this issue Feb 9, 2016 · 4 comments

Comments

@TriAnMan
Copy link

TriAnMan commented Feb 9, 2016

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.

@TriAnMan TriAnMan changed the title Proposal^ Proposal: partial objects, lazy load for field access Feb 9, 2016
@Ocramius
Copy link
Member

Ocramius commented Feb 9, 2016

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

DHager commented Feb 9, 2016

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

Ocramius commented Feb 9, 2016

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

tacman commented Jan 8, 2024

Partial objects have been deprecated/removed, some alternative solutions can be found here: #8471

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

No branches or pull requests

4 participants