-
Notifications
You must be signed in to change notification settings - Fork 936
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
Comments
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 |
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. |
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. |
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. |
A non-inverse
one-to-one
mapped aslazy="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-inverseone-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 theone-to-one
was eagerly loaded.#1947 exposes this trouble more obviously by fixing the subsequent bug, see these comments.
The text was updated successfully, but these errors were encountered: