July 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (ANN-140) Discriminator column not supported with JOINED strategy

by Gérald Quintana (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-140?page=co... ] Gérald Quintana commented on ANN-140: ------------------------------------- Using discriminator column with "joined" strategy used to work when we were using .hbm.xml files to describe ORM. Moreover it's clearly documentated: http://docs.jboss.org/hibernate/stable/core/reference/fr/html/inheritance... SInce we moved to annotations instead of XML files, we can't do that anymore except using secondary tables but it's painful. > Discriminator column not supported with JOINED strategy > ------------------------------------------------------- > > Key: ANN-140 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-140 > Project: Hibernate Annotations > Issue Type: Bug > Affects Versions: 3.1beta6 > Environment: Hibernate 3.1rc2, Hibernate Annotations 3.1b6 > Reporter: Steven Grimm > > Section 9.1.27 of the EJB3 persistence public draft says, "The DiscriminatorColumn annotation is used to define the discriminator column for SINGLE_TABLE and JOINED mapping strategies." But Hibernate ignores the DiscriminatorColumn annotation when the mapping strategy is JOINED; when a JOINED entity is persisted, its discriminator column is not included in the SQL "insert" statement, resulting in a not-null constraint violation if the discriminator column is marked NOT NULL in the database. > The JOINED strategy with discriminators is pretty ubiquitous in EJB3 sample code and tutorials out on the net, so lots of people are likely to run into this as they try out EJB3 for the first time. A few examples: > http://www.oracle.com/technology/tech/java/oc4j/ejb3/howtos-ejb3/howtoejb... > http://www.solarmetric.com/Software/Documentation/4.0.0EA/docs/full/html/... > http://www.caucho.com/resin-3.0/amber/tutorial/cmp-inherit/index.xtp -- 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

14 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4062) Functional inconsistency on session-proxy methods

by Peter Ladanyi (JIRA)

Functional inconsistency on session-proxy methods ------------------------------------------------- Key: HHH-4062 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4062 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Peter Ladanyi https://forum.hibernate.org/viewtopic.php?f=1&t=998536 -- 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

14 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-192) DigitsValidatorForNumber should strip trailing zeros

by Hardy Ferentschik (JIRA)

DigitsValidatorForNumber should strip trailing zeros ---------------------------------------------------- Key: HV-192 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-192 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 4.0.0.Beta2 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.0.0.Beta3 new BigDecimal( num.toString() ).stripTrailingZeros() should be used. This is consistent with the implementation of Digits in the legacy validator. See also https://forum.hibernate.org/viewtopic.php?f=9&t=998581 -- 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

14 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1574) AbstractEntityPersister.getNaturalIdentifierSnapshot doesn't work with many-to-one ids

by Russ Egan (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574?page=c... ] Russ Egan commented on HHH-1574: -------------------------------- I'm running into this too...not seeing a great workaround, apart from ditching the immutable attribute. > AbstractEntityPersister.getNaturalIdentifierSnapshot doesn't work with many-to-one ids > -------------------------------------------------------------------------------------- > > Key: HHH-1574 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574 > Project: Hibernate Core > Issue Type: Patch > Affects Versions: 3.1.2 > Reporter: Alex Burgel > Attachments: resolveentity.patch, resolveentity32.patch, testcase.zip > > > i just upgraded from 3.0.5 to 3.1.2, and i started seeing this problem. i'm not exactly sure where the bug is here, but this is what i'm seeing: > i have a class, Subscription, which has a natural-id of class Subscriber and Edition (excerpts of relevant mapping files below). > when Subscription is unloaded, if i make a change, then commit the session, i see this exception: > HibernateException: immutable natural identifier of an instance of Subscription was altered > this gets thrown from DefaultFlushEntityEventListener.checkNaturalId() line 80. > i traced through that method, this is what happens: > 1. in checkNaturalId, loaded == null , so getNaturalIdSnapshot() is called > 2. this ends up generating some sql that selects the SubscriptionId and EditionId from the Subscription row. > 3. the sql is generated in AbstractEntityPersister.getNaturalIdentifierSnapshot(), which calls hydrate for each returned column of the natural-id, > 4. but hydrate only returns the id, instead of the actual entity > 5. so this array of ids (instead of entities) ends up back in DefaultFlushEntityEventListener.checkNaturalId() as 'loaded', which gets compared to 'current' > the trouble is that 'current' contains the entities, but 'loaded' only contains the ids of those entites, so the natural-id check fails, and i get the exception. > this only happens when 'loaded' is null in checkNaturalId(). > the javadocs for hydrate say you have to call "resolve" afterwards... this isn't being done, so maybe thats the fix. if the natural-id is not just simple properties, then resolve should also be called. > <class name="Subscription" table="Subscriptions" batch-size="10"> > <id name="id" column="Id" type="int"><generator class="native" /></id> > <natural-id> > <many-to-one name="subscriber" class="Subscriber" column="SubscriberId" /> > <many-to-one name="edition" class="Edition" column="EditionId" /> > </natural-id> > .... > </class> > <class name="Subscriber" table="Subscriber"> > <id name="id" column="id" type="int"><generator class="native" /></id> > <map name="subscriptions" inverse="true" cascade="all,delete-orphan" batch-size="10"> > <key column="SubscriberId" /> > <map-key-many-to-many column="EditionId" class="Edition" /> > <one-to-many class="Subscription" /> > </map> > </class> -- 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

14 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3952) Enabling second level caching at runtime

by Galder Zamarreno (JIRA)

Enabling second level caching at runtime ---------------------------------------- Key: HHH-3952 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3952 Project: Hibernate Core Issue Type: New Feature Components: caching (L2) Reporter: Galder Zamarreno To be able to extend rolling upgrade strategies such as the one explained in http://www.jboss.org/community/docs/DOC-10910 to situations where 2nd level cache is used, some kind of dynamic switch for 2nd level cache would be required. The requirement comes from the fact that while the old cluster is running, users could update entities in the 2nd level cache after these entities have been read and loaded into the 2nd level cache in the new cluster. Since the old cluster and the new cluster does not communicate directly, invalidation messages from the old cluster would not be received by the new cluster and hence, the new cluster could be interacting with stale data. The most sensible thing here IMO would be to start the new cluster with 2nd level cache disabled and at some point, when the old cluster has been completely shut down, turn it on again. This would require exposing some kind of control to be able to do the switch. for example via JMX. -- 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

14 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4061) When using indexed list parameters in update hql, indexed parameters are not treated right

by ron piterman (JIRA)

When using indexed list parameters in update hql, indexed parameters are not treated right ------------------------------------------------------------------------------------------ Key: HHH-4061 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4061 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Reporter: ron piterman Attachments: hibtest.zip When using the hql: UPDATE EntityCls SET removed = current_date WHERE id in (?) the list parameter is treated as Long, causing a ClassCastException. When using UPDATE EntityCls SET removed = current_date WHERE id in (:ids) everything is fine. Attached is a maven project - unzip and run mvn install. -- 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

14 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-334) Create a builtin bridge for Character

by Hardy Ferentschik (JIRA)

Create a builtin bridge for Character ------------------------------------- Key: HSEARCH-334 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-334 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Fix For: 3.1.1 -- 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

14 years, 11 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4059) in set definitions named queries do not work as expected

by Stefan Endrullis (JIRA)

in set definitions named queries do not work as expected -------------------------------------------------------- Key: HHH-4059 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4059 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2 Environment: « Hide OS: Kubuntu 9.04 amd64, kernel 2.6.28-13-generic Java: java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) Hibernate: checked out from svn on 25.07.2009. Reporter: Stefan Endrullis Attachments: code.zip I've discovered a problem with named queries in hibernate's set definitions. For demonstration I've prepared a very small example implementation. It consists mainly of the following two classes (only most important attributes illustrated): class Account { Set<Transaction> transactions; } class Transaction { Account from; Account to; } I mapped both classes and their attribute with the help of hibernate. Thereby I used a named query to retrieve the list of transactions for an account, since this is the only way of avoiding redundance, I think. This is the mapping of the class Account: <hibernate-mapping> <class name="transactiontest.model.Account" table="account"> <id name="id" length="10"> <generator class="native"/> </id> <property name="name" length="255" not-null="true"/> <set name="transactions" table="transaction" inverse="true"> <key/> <one-to-many class="transactiontest.model.Transaction"/> <loader query-ref="transactions"/> </set> </class> <sql-query name="transactions"> <load-collection alias="tra" role="transactiontest.model.Account.transactions"/> <query-param name="id" type="integer"/> select {tra.*} from transaction tra where tra.from=:id or tra.to=:id </sql-query> </hibernate-mapping> When I try to get the transactions of an account via the getTransactions() method I do not get the expected result. But the named query seems to be correct because it works when I call it directly with the account id as parameter. For a fast reproduction I've created a minimal test program (junit test) and zipped it (see attachment). If you want to test it with your local MySQL database you can use the SQL script setup/mysql_setup.sql to setup the corresponding DB and the DB user. -- 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

14 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4058) build from svn (mvn install) fails

by Stefan Endrullis (JIRA)

build from svn (mvn install) fails ---------------------------------- Key: HHH-4058 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4058 Project: Hibernate Core Issue Type: Bug Components: build, core Environment: OS: Kubuntu 9.04 amd64, kernel 2.6.28-13-generic Java: java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) Hibernate: checked out from svn on 25.07.2009. Reporter: Stefan Endrullis Attachments: out.log I followed the instructions on https://www.hibernate.org/422.html in order to build the latest hibernate version (svn trunk), but the build failed with the following error message: [...] [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /home/stefan/programmierung/java/hibernate/core/core/src/main/java/org/hibernate/jdbc/ResultSetWrapper.java:[53,7] org.hibernate.jdbc.ResultSetWrapper is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet /home/stefan/programmierung/java/hibernate/core/core/src/main/java/org/hibernate/lob/SerializableBlob.java:[36,7] org.hibernate.lob.SerializableBlob is not abstract and does not override abstract method getBinaryStream(long,long) in java.sql.Blob /home/stefan/programmierung/java/hibernate/core/core/src/main/java/org/hibernate/lob/ClobImpl.java:[41,7] org.hibernate.lob.ClobImpl is not abstract and does not override abstract method getCharacterStream(long,long) in java.sql.Clob /home/stefan/programmierung/java/hibernate/core/core/src/main/java/org/hibernate/lob/BlobImpl.java:[39,7] org.hibernate.lob.BlobImpl is not abstract and does not override abstract method getBinaryStream(long,long) in java.sql.Blob /home/stefan/programmierung/java/hibernate/core/core/src/main/java/org/hibernate/lob/SerializableClob.java:[38,7] org.hibernate.lob.SerializableClob is not abstract and does not override abstract method getCharacterStream(long,long) in java.sql.Clob [...] The whole output of "mvn clean install" is attached. -- 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

14 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (EJB-454) implements PersistenceProviderResolverHolder and the default PersistenceProviderResolver

by Emmanuel Bernard (JIRA)

implements PersistenceProviderResolverHolder and the default PersistenceProviderResolver ---------------------------------------------------------------------------------------- Key: EJB-454 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-454 Project: Hibernate Entity Manager Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard -- 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

14 years, 11 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2009