August 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] (HHH-7520) BlobProxy.invoke Javadoc is incorrect

by Neale Upstone (JIRA)

11 years, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2721) PostgreSQLDialect: function md5() always returns a string value

by Dirk Leser (JIRA)

PostgreSQLDialect: function md5() always returns a string value --------------------------------------------------------------- Key: HHH-2721 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2721 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.4.sp1 Reporter: Dirk Leser Priority: Minor The md5() function always returns a string type and not the type given as parameter. Therefore the line registerFunction( "md5", new StandardSQLFunction("md5") ); has to be changed to registerFunction( "md5", new StandardSQLFunction("md5", Hibernate.STRING) ); in class org.hibernate.dialect.PostgreSQLDialect -- 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

11 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7304) NaturalIdResolutionCache not correctly filled on first persist when @GeneratedValue-@Id

by Frank Schwarz (JIRA)

NaturalIdResolutionCache not correctly filled on first persist when @GeneratedValue-@Id --------------------------------------------------------------------------------------- Key: HHH-7304 URL: https://hibernate.onjira.com/browse/HHH-7304 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.3 Reporter: Frank Schwarz {code:title=Employee.java|borderStyle=solid} @Entity public class Employee{ @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; @NaturalId(mutable = true) private String name; @NaturalId(mutable = true) private String surname; private String position; } {code} {code:title=NaturalIdTest1.java|borderStyle=solid} entityManager.getTransaction().begin(); Employee e = new Employee(); e.setSurname("Hans"); e.setName("Dampf"); e.setPosition("Junior"); entityManager.persist(e); entityManager.getTransaction().commit(); Session session = entityManager.unwrap(Session.class); Employee e2 = (Employee) session.byNaturalId(Employee.class) .using("surname", "Hans") .using("name", "Dampf") .load(); System.out.println(e2); {code} {code:title=NaturalIdTest2.java|borderStyle=solid} entityManager.getTransaction().begin(); Employee e = new Employee(); e.setSurname("Hans"); e.setName("Dampf"); e.setPosition("Junior"); entityManager.persist(e); // this is the only difference e.setPosition("Senior"); entityManager.getTransaction().commit(); Session session = entityManager.unwrap(Session.class); Employee e2 = (Employee) session.byNaturalId(Employee.class) .using("surname", "Hans") .using("name", "Dampf") .load(); System.out.println(e2); {code} The NaturalIdTest1 will issue an SQL statement for the find-by-natural-id-query; the NaturalIdTest2 does not. Put a breakpoint into NaturalIdResolutionCache#cache(Serializable, Object[]) and watch the pk-parameter to be {{null}} on the first invocation and not {{null}} on the second invocation. If the @Id-field is not @GeneratedValue, the first invocation of NaturalIdResolutionCache#cache will be already correct. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3788) FirebirdDialect: current_date() function

by Rafael Santini (JIRA)

FirebirdDialect: current_date() function ---------------------------------------- Key: HHH-3788 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3788 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.3.1 Environment: 3.3.1, Firebird 1.5 Reporter: Rafael Santini The FirebirdDialect does not supports current_date() function. A select like "select * from test where dt < current_date()" causes the following exception: --- Caused by: org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544569. Dynamic SQL Error SQL error code = -104 Token unknown - line 1, column X ( --- In MySQLDialect.java there is: registerFunction("current_date", new NoArgSQLFunction("current_date", Hibernate.DATE, false) ); But in InterbaseDialect.java or FirebirdDialect.java there is not the current_date function. -- 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

11 years, 4 months

3
5
0 / 0

[Hibernate-JIRA] (HHH-7437) Classcast issue with new property auditing feature of Envers(withModifiedFlag)

by Jethro Bakker (JIRA)

11 years, 4 months

4
7
0 / 0

[Hibernate-JIRA] (HHH-7561) PersistenceUnitUtil.getIdentifier returning null for a persisted proxy

by Matt Todd (JIRA)

11 years, 4 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2448) Generate identical column aliases among cluster

by Loïc LEFEVRE (JIRA)

Generate identical column aliases among cluster ----------------------------------------------- Key: HHH-2448 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2448 Project: Hibernate3 Type: Improvement Components: query-sql Versions: 3.2.2 Environment: Hibernate version: 3.2.2, 2.1.8 Database: Oracle 9.2.0.8 Reporter: Loïc LEFEVRE Attachments: report_1.txt, report_2.txt Among our weblogic cluster (12 instances), we can see that a query can have different column aliases. Although all seems correct, when regarding database reports like StatsPack or Spotlight we can see that because of these different aliases, the reports are wrong. Indeed, a resource consuming query can see its associated report properties (cpu usage, buffer gets, number of executions...) divided by the number of weblogic instances of our cluster (i.e. divided by 12) thus preventing us to pinpoint the queries to look at. On a 3 instances cluster, we can see this report: REPORT#1: one statement with a poor number of buffer gets/execution is reported splitted in 3, see the alias generated for column DTO.CREATION_DATE for example On a 4 instances cluster, we can see this report: REPORT#2: one statement responsible of the latch free/cache buffers chains wait events splitted in 4, note the column alias generated fordeffcashcy0_.BEST_EXPECTED_CY More than confusing the DBAs about the same query with n different "faces", our reports don't show us all the queries to look at: indeed, in our "Top 50 queries", a lot of them are duplicates! Also the memory required in the SGA to store the queries, the execution plan and so on is increased... Finally, although the column aliases can have up to 30 characters under Oracle, the limit is set to 10, why? -- 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

11 years, 4 months

15
43
0 / 0

[Hibernate-JIRA] Created: (HHH-5255) Bytecode instrumented byte[] lazy properties do not work

by Kyrill Alyoshin (JIRA)

Bytecode instrumented byte[] lazy properties do not work -------------------------------------------------------- Key: HHH-5255 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5255 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate-3.5.2, Oracle 10g Reporter: Kyrill Alyoshin Well, I have an entity that stores a byte[] property as a Blob. @Lob @Basic(optional = false, fetch = FetchType.LAZY) public byte[] getContent() { return content; } The content can be pretty large, so I marked it as lazy and to enable lazy property fetching I am instrumenting the class at build-time using org.hibernate.tool.instrument.javassist.InstrumentTask just as the documentation says. However, when I call session.merge on this entity, I can get this stacktrace: java.lang.ClassCastException: org.hibernate.intercept.LazyPropertyInitializer$1 cannot be cast to [B at org.hibernate.type.AbstractLongBinaryType.toInternalFormat(AbstractLongBinaryType.java:46) at org.hibernate.type.AbstractBynaryType.isEqual(AbstractBynaryType.java:134) at org.hibernate.type.NullableType.isEqual(NullableType.java:233) at org.hibernate.type.MutableType.replace(MutableType.java:60) at org.hibernate.type.TypeFactory.replace(TypeFactory.java:548) at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:495) at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:423) at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:234) at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:84) at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:859) at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:843) at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:847) It seems to work fine on session.get() I think it is a bug. -- 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

11 years, 4 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7257) PersistentSet is initialized by criteria query with incomplete data

by Peter Fodor (JIRA)

PersistentSet is initialized by criteria query with incomplete data ------------------------------------------------------------------- Key: HHH-7257 URL: https://hibernate.onjira.com/browse/HHH-7257 Project: Hibernate ORM Issue Type: Bug Components: query-criteria Affects Versions: 4.1.2, 3.5.5 Environment: Hibernate 4.1.2 and 3.5.5 java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) Ubuntu Linux 11.10 PostgreSQL 9.1, HSQLDB 2.2.8 Reporter: Peter Fodor Attachments: hibernate-criteria-testcase.zip A criteria query with a filter (to the elements of a one-to-many relation) can initialize the persistent set with so that it returns not all items. More detailed description: 1a. A bean is a simple entity 1b. A bean has multiple B beans 2. Query A bean with a filter to B 3a. The returns good result in the terms of A 3b. The set of returned A bean (which contains B instances) does not contains every referenced B item 4. After querying A items again with session.get() the returned A instances neither have the full set (with every B reference) Expected behavior: 1. The Set of A instances should contain every referenced B item. (I know it can not be done with one query in general case) 2. If I query the same items with session.get() it shouldn't be affected by previous query and its set should contain every item. (I think this is the most serious problem) 3. The PersistentSet shouldn't marked with initialized=true, if its content can not be guaranteed that it contains every item. Note: The set of the same query is different (and contains every item), if its PersistentSet is initialized in the same session by an other query. (e.g. with a previous session.get().toString()) For more detailed description please check the test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-397) DefaultTraversableResolver uses multiple reflection calls to check for a JPA 2 environment

by Hardy Ferentschik (JIRA)

DefaultTraversableResolver uses multiple reflection calls to check for a JPA 2 environment ------------------------------------------------------------------------------------------ Key: HV-397 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-397 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.x {{DefaultTraversableResolver}} uses multiple reflection calls to check for JPA2. This is necessary due to incomplete JPA2 specification/implementation artifacts. See also HV-374. This multiple checks can be reduced at some point. -- 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

11 years, 4 months

1
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2012