[Hibernate-JIRA] Created: (BVAL-72) Validating an object multiple times if in a different branch of the graph
by Emmanuel Bernard (JIRA)
Validating an object multiple times if in a different branch of the graph
-------------------------------------------------------------------------
Key: BVAL-72
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-72
Project: Bean Validation
Issue Type: Improvement
Components: spec-general
Reporter: Emmanuel Bernard
3-F) 3.5.1 "The InvalidConstraint objects reflect the path to reach the
object from the root validated object": What happens if the same invalid
object is referenced twice by an object (see the example below). Will
there be generated two InvalidConstraint objects one reflecting the path
b.ref1.value and one for b.ref2.value? If the referenced invalid object
is only validated once, which property path will be used?
class A {
@NotNull String value = null;
}
class B {
@Valid A ref1;
@Valid A ref2;
}
b = new B();
b.ref1 = new A();
b.ref2 = ref1;
Only one ConstraintViolation is created.
from 3.1.3
The @Valid annotation is applied recursively. A conforming
implementation avoids infinite loops by validating an
object the first time it is encountered in the graph, and ignores it
if it is encountered through at different path.
The path chosen is not defined. Any alternative?
Fine with me, I just wanted to have that clarified.
I thought about that a bit.
We have the current rule wich is simple but a bit indeterministic in the case an object is referenced twice in an object graph
Or we could adopt the following rule
For a given object graph branch, the same instance cannot be validated several times.
This would lead to the validation of the same object several times provided it is in different branches
in Sebastian's example
b.ref1 and b.ref2 would be validated and generate the same constraintViolations (with different paths)
Opinions?
- only one validation pass per instance (with some indeterminism)
- several validation pass and error reports provided that the object graph branches are different?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[Hibernate-JIRA] Created: (BVAL-59) Rethink the group sequence inheritance rules
by Emmanuel Bernard (JIRA)
Rethink the group sequence inheritance rules
--------------------------------------------
Key: BVAL-59
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-59
Project: Bean Validation
Issue Type: Improvement
Components: spec-general
Reporter: Emmanuel Bernard
Sebastian wrote:
3-F) 3.4 "Two group sequences must not share the same group name in a
given object graph". Does this mean If an object of type A references an
object of type B and A and B have a group sequences with the same name
this would result to an exception? Why would such a limitation be
necessary? Or is the term "object graph" misplaced here?
Emmanuel replied:
"When an object graph is validated (through the use of @Valid), the children elements of the graph inherit the sequence definitions of their parent."
Yes this was the intend. Because group sequence definitions are inherited from a parent to a child, the rule makes sense.
I think you assumed that a group sequence was not inherited. Children would be validated against the expanded groups of their parents.
Let's go back to the drawing board (in a different thread) and evaluate the merit of both rules using common usecases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[Hibernate-JIRA] Created: (HHH-3528) FETCH JOIN query doesn't work in a StatelessSession
by Oscar Pearce (JIRA)
FETCH JOIN query doesn't work in a StatelessSession
---------------------------------------------------
Key: HHH-3528
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3528
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.2.6
Environment: Hibernate core 3.3.1 and 3.2.6, HSQLDB 1.8.0 and PostgreSQL 8.1
Reporter: Oscar Pearce
Attachments: slsession.zip, StatelessSessionImpl.patch
A query with an explicit JOIN FETCH, such as the following:
from DomainObject obj join fetch obj.a
fails when run in a StatelessSession, giving the following exception:
org.hibernate.SessionException: proxies cannot be fetched by a stateless session
at org.hibernate.impl.StatelessSessionImpl.immediateLoad(StatelessSessionImpl.java:243)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:95)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:140)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:190)
The attached zip file contains a small project (buildable with maven) that demonstrates the problem. Applying the patch to StatelessSessionImpl fixes it.
The cause of the problem is with the internalLoad method of StatelessSessionImpl. The method currently first tries to generate a proxy and, only if no proxy is available, then it uses the data that it loaded as part of the query. The patch changes it to use any loaded data from the query in preference to creating a proxy. (I suspect that the check for eager should be omitted, and that an exception should be thrown if getEntity fails and no proxy can be created, but I don't know the code well enough to be sure of that.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months