[Hibernate-JIRA] Created: (HHH-3642) EJB3 inheritance strategy TABLE_PER_CLASS does not work on HSQLDB
by Wolfgang Knauf (JIRA)
EJB3 inheritance strategy TABLE_PER_CLASS does not work on HSQLDB
-----------------------------------------------------------------
Key: HHH-3642
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3642
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: JBoss 5.0GA, Java 1.6, Hypersonic 1.8.0.8
Reporter: Wolfgang Knauf
Attachments: InheritanceTablePerClass.ear
I use an EJB3 entity bean with inheritance strategy "TABLE_PER_CLASS":
@Entity
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public abstract class Base implements Serializable
{
...
When loading a list of base classes, all subclass fields are null. The union subclause in the query does not work on HSQLDB.
Attached is a full EJB sample, runnable on JBoss 4.2/5.0 (project export of Eclipse 3.4/WebTools 3.0 with sources). After deploying, it can be tested by browsing to http://localhost:8080/InheritanceTablePerClassWeb/
See this output:
...
Loading ALL
Item: Child 1, child field 1: null
Item: Child 2, child field 2: null
Item: Child 3, child field 3: Field of Child3
...
Here, all childs are loaded. The fields of type "Child1" and "Child2" are null, fields of type "Child3" are filled.
This is probably a duplicate of http://opensource.atlassian.com/projects/hibernate/browse/HHH-2920
The described workaround to change all NULL expressions to "cast (null as VARCHAR)" results in a working query, but I see no chance to pre-configure this query in the entity manager.
I created another bug, because the impact is different (it breaks a feature of EJB3), and so I consider severity to be higher.
--
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, 9 months
[Hibernate-JIRA] Created: (BVAL-41) Support BeanInfo implementation to receive property names
by Emmanuel Bernard (JIRA)
Support BeanInfo implementation to receive property names
---------------------------------------------------------
Key: BVAL-41
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-41
Project: Bean Validation
Issue Type: Improvement
Components: spec-general
Reporter: Emmanuel Bernard
Michael
- Why section 3.1.2 requires properties to follow the JavaBeans naming
convention? In many non-English speaking countries (and projects with
ridiculous managers/code standards), other prefixes are used and
proper BeanInfo implementations are supplied. Although it is not
pretty at all, since they are following the JavaBean spec, I don't
think Bean Validation shouldn't work out-of-the-box for them;
Emmanuel
I reused the Java Persistence wording actually and I explicitly reference
the Introspector class. Do people think we should be more cautious here?
Speaking for France, I've never seen a project bothering about get/is/set
and BeanInfo. People happily used frenglish: getCafeAuLait()
Actually I've never seen anybody from the server side bothering about
BeanInfos ;)
Michael
I've got an interesting case for that one: in some JVM languages,
another standard is used to represent properties. Let's take, for
instance, Scala.
In Scala, one could write a bean like:
@BeanInfo
class Person(var id : Long, var name : String, var surname : String)
Scala already maps vars as properties creating a private var, a public
getter method named like the var and a setter like var_=. Something
like:
private var _id : Long
def id = _id
def id_=(newId: Long) = _id = newId
that would translate to Java methods id and id_$eq (since = cannot be
used in method names). So, when one use @BeanInfo, a proper BeanInfo
subclass is generated by the compiler providing that mapping.
Given how popular JVM languages are getting, not following a spec in
another one and causing property support in those languages to fail to
work doesn't seem nice.
BTW, please let the JPA EG know about his as well.
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3831) composite-id + generator +foreign
by Sandeep Vaid (JIRA)
composite-id + generator +foreign
---------------------------------
Key: HHH-3831
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3831
Project: Hibernate Core
Issue Type: Bug
Components: core
Reporter: Sandeep Vaid
Attachments: ProductAndProductBasicDetails.txt, ProductAndProductBasicError.txt
I have 2 classes viz. Product and ProductBasic which has one-to-one relationship.
Product is mapped to a table PRODUCT which has PRODUCTID as PK.
ProductBasic is mapped to a table PRODUCTBASIC which has PRODUCTID,USETYPE and STARTTTIMESTAMP as composite key. Also PRODUCTID
is the foreign key referencing PRODUCT table...
When i am saving Product (with cascade for ProductBasic):
For Product, it's taking persister.identifierType as org.hibernate.type.CustomType
For ProductBasic, it's taking persister.identifierType as org.hibernate.type.ComponentType
Assume productId='1'
When i call session.save(product),
a) For Product: it tries to find hashmap of id=1 using org.hibernate.type.StringType.getHashCode() which comes out to be 49 (ASCII)..
b) For ProductBasic: it tries to find hashmap of id=1 using org.hibernate.type.ComponentType.getHashCode() and throws exception:
org.hibernate.PropertyAccessException: IllegalArgumentException occurred calling getter of com.tietoenator.lis.db.impl.product.bo.CompProductBasicBO.useType
Does it treating ProductBasic as component because it's productId value depends upon Product.productId? Even if it treats
ProductBasic as component, why it is not fetching the proper hashCode() and throwing exception?
--
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, 9 months
[Hibernate-JIRA] Créée: (HHH-2060) To be able to use <generator> with <composite-id>
by Xavier Brénuchon (JIRA)
To be able to use <generator> with <composite-id>
-------------------------------------------------
Key: HHH-2060
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2060
Project: Hibernate3
Type: Improvement
Versions: 3.2.0.cr4
Environment: Hibernate 3.x
Reporter: Xavier Brénuchon
Hello,
This is the continuation of HB-389
We develop an application which has very strong need for performance with several tens of million recordings. Partitioning is a need.
So for that, I use <composite-id>. But my primary key is not a natural key, but a real technical key :
- column of partitioning for optimization of the data base
- column of technical id
So I need to have a generator, for exemple :
<composite-id name="id" class="IdPartition">
<key-property name="org" type="string" column="ORG"/>
<key-property name="id" type="long" column="ID"/>
<generator class="fr.test.xavier.IdPartitionGenerator">
<param name="table">TAB_SEQ</param>
<param name="column">LAST</param>
</generator>
</composite-id>
The good news is that Hibernate can use that (HB-389).
In fact, it is enough to modify the DTD to authorize <generator> in <composite-id> and it is all. The current code of Hibernate manages it very well.
Is it possible that Hibernate is enriched by this functionality?
--
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, 9 months