[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
[Hibernate-JIRA] Created: (HHH-3522) Null value cannot be cache using hibernate
by Lao Shing Kit (JIRA)
Null value cannot be cache using hibernate
--------------------------------------------
Key: HHH-3522
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3522
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Environment: Hibernate 3.3.1, Ehcache 1.5, Java1.5
Reporter: Lao Shing Kit
I'm using Hibernate with 2nd level cache using Ehcache. We found that if the result returned using session.get() (searching by primary key) is NULL, the value will not be cached in 1st level and 2nd level cache and SQL will be fired to database. There is no problem if the value retuurned is not null for the same entity. I have debug using the hibernate and ehcache source and I'm sure that the cache is enabled and called properly. Actually the null value is expected to be cached also. I have browser all hibernate and ehcache documentation and forum and no related config is available. So, is it a bug?
Thanks all for your help!
--
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-3455) Component polymorphism (<subclass> within <component>)
by Jasper Blues (JIRA)
Component polymorphism (<subclass> within <component>)
------------------------------------------------------
Key: HHH-3455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3455
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Jasper Blues
The following feature request occurs on the Hibernate forums from time to time - it would be especially useful in mapping complex legacy schemas:
<class name="Critter">
<component name="breathingStrategy" class="BreathingStrategy">
<discriminator column="BREATHING_STRATEGY" type="integer" />
<subclass name="Lungs" discriminator-value="0" >
<set name="alveoli">
<key column="CRITTER_ID" />
<one-to-many class="Alveolus" />
</set>
</subclass>
<subclass name="Gills" discriminator-value="1" >
<set name="alveoli">
<key column="CRITTER_ID" />
<one-to-many class="Gill" />
</set>
</subclass>
</component>
</class>
Will a patch that implements this feature be accepted?
What do you think if there was an option to inherit a discriminator from the owning entity? How about some convention over configuration? By default the discriminator from the owning entity is inherited, unless one is supplied at the component level.
Would an equivalent annotation mapping be required?
--
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