September 2010 - hibernate-issues

[Hibernate-JIRA] Created: (ANN-682) @ForeignKey override of @MappedSuperclass

by Christian Bauer (JIRA)

@ForeignKey override of @MappedSuperclass ----------------------------------------- Key: ANN-682 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-682 Project: Hibernate Annotations Issue Type: New Feature Components: binder Reporter: Christian Bauer Put this @ManyToOne in a @MappedSuperclass: @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "CREATED_BY_USER_ID", nullable = false) // Ideally this foreign key should be ON DELETE SET NULL, however... // Hibernate can't rename these so subclasses would get the same FK constraint name. This doesn't // work, so we need to let Hibernate create a random identifier for these. We could fix this in the // DatabaseObjects.hbm.xml file but we can't even address it because the name is random. This sucks. // So we do a manual SET NULL|DEFAULT when userHome.remove() is called. // @org.hibernate.annotations.ForeignKey(name = "FK_WIKI_NODE_CREATED_BY_USER_ID") protected User createdBy; Now all subclasses get that foreign key constraint name in the database catalog, which isn't possible - constraint names have to be unique. -- 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

13 years, 7 months

6
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5558) Change made so that temp tables need not to be deleted, they get deleted automatically in Sybase.

by Strong Liu (JIRA)

Change made so that temp tables need not to be deleted, they get deleted automatically in Sybase. -------------------------------------------------------------------------------------------------- Key: HHH-5558 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5558 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Strong Liu Assignee: Strong Liu Fix For: 3.6.0.CR1 > > Change made so that temp tables need not to be deleted, they get deleted > automatically in Sybase. > Hibernate does not isolate operations on temp tables in a separate transaction because: 1) "ddl in trans" is set (iirc, this is a requirement for hibernate to work properly) 2) (DatabaseMetaData.dataDefinitionCausesTransactionCommit() returns false). In other words, operations on temp tables are executed in the current transaction. Since other operations can be executed later in the same transaction, I though it was a good idea to manually drop the temp tables when they are no longer needed, instead of waiting for them to be cleaned up automatically on commit. If "ddl in trans" is no longer needed or if you think it is more correct to wait until the transaction is committed for temp table cleanup, then it should be OK to make this change to the dialect. <AJ> While I do this change I see some performance improvement and no regression in the tests (I ran around 2000 tests of testsuite). If you see the same in your testing it is worth doing. > > Sybase supports alias length upto 30 characters (more than 10 as it is > indicated) > As far as I know, there should be no problem making this update. -- 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

13 years, 7 months

1
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-1829) Allow join on any property using property-ref

by Patrick Gallagher (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?page=c... ] Patrick Gallagher commented on HHH-1829: ---------------------------------------- Is there an update anyone can provide on this issue? Unfortunately for us, we need this ability to map our legacy database and redesigning the schema isn't an option. > Allow join on any property using property-ref > --------------------------------------------- > > Key: HHH-1829 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829 > Project: Hibernate Core > Issue Type: New Feature > Components: metamodel > Affects Versions: 3.2.0 cr1, 3.2.0.cr2 > Reporter: Maarten Winkels > Assignee: Anthony Patricio > Attachments: AbstractJoinTest.java, HHH-1829-3.2.8-SNAPSHOT.patch, HHH-1829-mwinkels.patch, hhh-1829.patch, JoinNoPropertyRefTest.java, JoinPropertyRefTest.java, Person.hbm.xml, Person.java, PersonNoPropertyRef.hbm.xml > > > Currently joining tables for one class (uing the <join...> tag) is only supported for the id property. The property-ref is allowed on the <key..> tag inside the <join..> tag, but this is ignored. -- 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

13 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5564) Upgrade to Infinispan 4.2.x

by Galder Zamarreno (JIRA)

Upgrade to Infinispan 4.2.x --------------------------- Key: HHH-5564 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5564 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5.6, 3.6.0.CR1 Currently, this is 4.2.0.ALPHA1 -- 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

13 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-210) Make sure JTA / Java EE plays well with Bean Validation + JPA when exceptions occurs

by Emmanuel Bernard (JIRA)

Make sure JTA / Java EE plays well with Bean Validation + JPA when exceptions occurs ------------------------------------------------------------------------------------ Key: BVAL-210 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-210 Project: Bean Validation Issue Type: Improvement Reporter: Emmanuel Bernard Not a BV issue per se but when a ConstraintViolationException is raised during a flush operation in JPA and the flush operation is triggered during the beforeCommit phase of the Tx, there is a loophole - JPA wraps the exception into a RollbackException (bad in itself btw as it's not consistent with what happens when the user manually calls flush()) - JPA mark the Tx as setRollbackOnly() Some Tx managers (eg. JBoss TS) do not report the cause exception because it considers setRollbackOnly and its associated stacktrace as more important (information wise) as the original exception. A method like setRollbackOnly(rootException) could solve the problem. For more background information, see https://jira.jboss.org/browse/JBTM-575 -- 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

13 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-527) Hibernate Search Not giving any errror when @DocumentId not mentioned, but hangs at configuration.buildSessionFactory()

by Kiran Narasareddy (JIRA)

Hibernate Search Not giving any errror when @DocumentId not mentioned, but hangs at configuration.buildSessionFactory() ----------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-527 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-527 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Environment: Hibernate core : 3.3.1 GA, Hibernate Annotations : 3.4.0.GA, Hibernate commons Annotations : 3.1.0 GA, Lucene core 2.4.1 Mysql Community 5.0.41 Reporter: Kiran Narasareddy Priority: Minor Consider a case in which primary key is associated with only Base class, with no primary key in any other subclasses marked for Lucene's document id. Now, if this attribute is not annotated with @DocumentId, hibernate engine shows no errors, but it hangs up at configuration.buildSessionFactory(); and doesn't move forward. The moment the annotation is added, the SessionFactory gets built and the application works. Example Model : Aobject.java : long id; (this is the intended field to be taken as documentID for lucene ) MyObject extends Aobject (This class is to be indexed.It has no id field of its own, the same id from AObject acts as PK for MyObject Also) -- 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

13 years, 7 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5546) @Where and eager @ManyToMany makes em.find return null with Oracle9iDialect

by Johan Andrén (JIRA)

@Where and eager @ManyToMany makes em.find return null with Oracle9iDialect --------------------------------------------------------------------------- Key: HHH-5546 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5546 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.2.4.sp1 Reporter: Johan Andrén Attachments: wherebug.tar.gz A many-to-many relation between class A and class B is annotated with FetchType.EAGER and a @Where that limits what of the entries from table B that should be included depending on if property in B is null. For HSQL it generates something like this SELECT A.*, A_TO_B.*, B.* FROM A LEFT OUTER JOIN A_TO_B ON A.id=A_TO_B.a_id LEFT OUTER JOIN B ON A_TO_B.b_id=B.id AND (B.SOME_PROPERTY IS NULL) WHERE A.id = ? which works correctly, but for oracle9 we get this SELECT A.*, A_TO_B.*, B.* FROM A, A_TO_B, B WHERE A.id = A_TO_B.a_id(+) AND A_TO_B.b_id = B.id(+) AND ( B.SOME_PROPERTY IS NULL ) AND calendar_event.id = ? Which makes em.find(A.class, idForAnExistingA) return null if there only is Bs with someProperty=null in the database for the given A (no rows returned from the query). Not sure how to make a runnable testcase, attached a maven project with annotated classes and code that describes the steps to reproduce but is not runnable as is. -- 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

13 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3976) NPE when eager fetching joined component with native SQL query

by Franz Allan Valencia See (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-3976 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3976 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.2.0.ga Reporter: Franz Allan Valencia See Priority: Critical Given a Hibernate Mapping with formula and named sql query, When accessing named sql query, NPE is thrown. This is basically a duplicae of HHH-2225. But since I cannot edit that to change it's Priority, I created a dupe. Feel free to close this if HHH-2225 has been edited to a higher priority. IMHO, it should be of a higher priority because AFAIK there are no decent workaround for this. -- 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

13 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3339) Query cache stops working after object save

by Alex Oleynikov (JIRA)

Query cache stops working after object save ------------------------------------------- Key: HHH-3339 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3339 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, MS SQL 2005 Database. Windows XP SP2 Reporter: Alex Oleynikov It seems like HB Query cache stops working as soon as given object type is being saved (it does not matter if it was save to existing object or insert of new object instance). The code looks like this. Where User is just a primitive POJO with couple of properties. // #1 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // #2 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // insert new User object user = new User(); user.setUserID((int)(Math.random() * Integer.MAX_VALUE)); user.setUserName("Ten"); session.beginTransaction(); session.save(user); session.getTransaction().commit(); // #3 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // #4 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); >From MS SQL Profiler I can clearly see that no queries is executed for #2 (e.g. it hit the cache), but queries are executed for #3 and #4. From HB debug log I see following: For #2 Query (cache is hit) - correct: 06:54:25,337 DEBUG StandardQueryCache:102 - checking cached query results in region: org.hibernate.cache.StandardQueryCache 06:54:25,337 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,337 DEBUG StandardQueryCache:117 - returning cached query results During User insert: 06:54:25,368 DEBUG UpdateTimestampsCache:65 - Invalidating space [USERS], timestamp: 4967466866147328 For #3 Query: 06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888 06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date For #4 Query (or any subsequent query for this matter): 06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888 06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date Please note the timestamp numbers for #4 query - even though I would expect query to be re-cached in #3, it still shows old timestamp. So I may think that when re-caching a query it does not update cache entry timestamp which is not up-to-date due to save(). -- 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

13 years, 7 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5556) @Column annotation - nullable default value

by Daniel Migowski (JIRA)

@Column annotation - nullable default value ------------------------------------------- Key: HHH-5556 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5556 Project: Hibernate Core Issue Type: Bug Environment: Hibernate 3.3.1, PostgreSQL 8.3 Reporter: Daniel Migowski We have an entity attribute like this: @Column(updateble=false) double quantityInInvoice; This column is considered nullable in the Hibernate meta data because the @Column annotation contains another attribute named "nullable" which defaults to true. I don't know if this is an specification error but for primitive datatypes the column should never be nullable IMHO. We found this out because we modified Hibernate locally to create and update the NOT NULL contraints on tables in the database. Workaround: Set nullable=false explicitely in the @Column annotation. -- 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

13 years, 7 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2010