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

Non-inverse no-proxy one-to-one are eager loaded #1960

Open
fredericDelaporte opened this issue Jan 6, 2019 · 4 comments
Open

Non-inverse no-proxy one-to-one are eager loaded #1960

fredericDelaporte opened this issue Jan 6, 2019 · 4 comments

Comments

@fredericDelaporte
Copy link
Member

A non-inverse one-to-one mapped as lazy="no-proxy" is not actually lazy, it is eager loaded.

This is not the same than #1087, which is about the lazy="proxy" case, which is considered invalid on an non-inverse end. But the case here is supposed to be the valid way of having a non-inverse one-to-one lazy.

This trouble is see-able with LazyOneToOneTest.Lazy. The test does not fail to date due to a subsequent bug, but if checking the emitted SQL query, we can see that the one-to-one was eagerly loaded.

#1947 exposes this trouble more obviously by fixing the subsequent bug, see these comments.

@bahusoid
Copy link
Member

bahusoid commented Jul 3, 2023

but if checking the emitted SQL query, we can see that the one-to-one was eagerly loaded.

It's about not constrained one-to-one behavior. It's eager loaded to check if association is really exists. I don't think it has anything to do with no-proxy

@fredericDelaporte
Copy link
Member Author

It has something to do with "no-proxy", theoretically. "no-proxy" causes the association owner to become a proxy for allowing lazy-loading of the association property, like it is done on entities having lazy properties. In such case, it does not need to know on entity-loading whether the association exists or not, since the association property is instrumented to query the database on first access. Nothing will prevent it yielding null at that point if the association does not exist.

That said, technically, it needs some special handling compared to a no-proxy many-to-one: for the many-to-one, the no-proxy instrumented property do not even need to query the database when the association does not exists, since the information is stored in the foreign key of the owner table (excepted with not-found="ignore" mappings): if it is null, no need to query the associated table. With unconstrained one-to-one, that is not a foreign key we have in the owner table, but only its primary key, and the associated table is referencing it.

@bahusoid
Copy link
Member

bahusoid commented Jul 3, 2023

it does not need to know on entity-loading whether the association exists or not

So I would call it a missing feature "Lazy loading support for nullable entity with no-proxy mapping". That includes both not constrained one-to-one and not-found ignore many-to-one mappings.

Currently our interceptor supports only initializing existing proxy. And query is triggered by Loader to determine if a proxy needs to be registered in session or null association (which is also cached). This logic needs to be moved to interceptor.

@fredericDelaporte
Copy link
Member Author

I do not consider it a missing feature. It looks to me as a shortcoming of the current implementation, which renders the lazy property meaningless in these cases. The current implementation is fine for many-to-one which does not use not-found ignore. But for these other cases, the way it currently works, it does nothing else on principle than an eager fetch, which is of course not lazy.

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

No branches or pull requests

2 participants