February 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4836) Infinispan: 2L QueryCache don't considers cached queries which belong to current transaction

by Guenther Demetz (JIRA)

Infinispan: 2L QueryCache don't considers cached queries which belong to current transaction -------------------------------------------------------------------------------------------- Key: HHH-4836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4836 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1 Environment: 3.5.0.Beta3, SQLServerr2008, integration with JTA Reporter: Guenther Demetz When looking for a cached Query in 2L-cache, QueryResultsRegionImpl(BaseRegion) does temporary suspend the current transaction. QueryResultsRegionImpl(BaseRegion).suspendAndGet(Object, FlagAdapter, boolean) line: 205 In this way only committed queries from already closed transactions are considered to be hit. Cached queries put by the current transaction are totally ignored! This is in my opinion a bug, because it changes behavior and degrades the efficiency of the 2L QueryCache in respect to other 2L-implementations (for example EHCache). Furthermore there is no reason to ignore cached queries deriving from current transaction: the up-to-date-ness is checked anyway by the StandardQueryCache.isUpToDate() call. Proposed solution: simply not suspend current transaction when looking for cached querys, then queries put by the current transaction are automatically considered as candidates for a hit. -- 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, 10 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3125) BigDecimal support for id generator from DB sequence

by Tomas Rada (JIRA)

BigDecimal support for id generator from DB sequence ---------------------------------------------------- Key: HHH-3125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3125 Project: Hibernate3 Issue Type: New Feature Environment: Hibernate 3.2, Oracle 10 Reporter: Tomas Rada Currently with using BigDecimal as entity id is thrown exception " this id generator generates long, integer, short or string" - class "IdentifierGeneratorFactory". Is there possibility to add BigDecimal support for id generator? -- 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, 10 months

6
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4639) Allow JPA SequenceGenerator (SequenceHiLoGenerator) generate BigInteger value

by Alexey Tomin (JIRA)

Allow JPA SequenceGenerator (SequenceHiLoGenerator) generate BigInteger value ----------------------------------------------------------------------------- Key: HHH-4639 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4639 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-Beta-2 Environment: 3.5.0-Beta-2 from jboss-6.0.0.M1 Oracle 10g Reporter: Alexey Tomin Attachments: BigInteger.patch In database (oracle) we used number(38) identifiers create sequence T_SEQ minvalue 1 maxvalue 999999999999999999999999999 start with 10000000000000044968 increment by 1; Version 3.5.0-beta-2 can not generate identifiers more, then long (number(19)). I create minimal (no optimal) patch -- 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, 10 months

2
2
0 / 0

[Hibernate-JIRA] Closed: (HHH-1936) IdentityGenerator doesn't support BigInteger as a valid identity type.

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936?page=c... ] Steve Ebersole closed HHH-1936. ------------------------------- Assignee: Steve Ebersole Resolution: Duplicate Please try this out and report any issues back against HHH-4905. > IdentityGenerator doesn't support BigInteger as a valid identity type. > ---------------------------------------------------------------------- > > Key: HHH-1936 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Hibernate 3.0.5, Sybase 12.05, Window/ Unix > Reporter: Leonid Shtivelman > Assignee: Steve Ebersole > Attachments: IdentifierGeneratorFactory.java > > > Identity generator strategy doesn't support BigInteger as a valid id type. This causes problem with Sybase which requires identity column to be numeric. It would seem an obvious way to get around this problem is to set column mapping to long in hibernate xml and the actual java object. This will solve obvious problem of creating identity, but will cause performance problem on selection. In order for Sybase to use index for parameter query the variable type of the parameter and column index type has to be the same. If ones maps column type to Long, Hibernate will use JDBC method setLong(long) to set value in the prepared statement. This will cause mismatch between parameter type and column index type, and Sybase will not use index to locate index. As you can see this is a big problem for anyone that is using identity columns Sybase and Hibernate -- 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, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3968) Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323]

by Jonathan Mastin (JIRA)

Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323] -------------------------------------------------------------------------------------------------------- Key: HHH-3968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3968 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: HSQLDB: 1.8.0.9 Reporter: Jonathan Mastin Problem --------------- When using HSQLDialect, the following code fails during schema creation: @Entity public class Test { @Id @GeneratedValue(strategy = GenerationType.AUTO) private BigInteger id; } Log output: ---------------- ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Unsuccessful: create table Test (id numeric generated by default as identity (start with 1), primary key (id)) ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Wrong data type: id in statement [create table Test (id numeric generated by default as identity (start with 1)] Expected --------------------------------- The column type is being set as "numeric", but it needs to be set as "integer" or "bigint" for HSQL to be able to parse. >From the HSQL manual: "The supported form is(<colname> INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH n, [INCREMENT BY m])PRIMARY KEY, ...). Support has also been added for BIGINT identity columns. As a result, an IDENTITY column is simply an INTEGER or BIGINT column ..." -- 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, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4905) Allow consistent handling of numeric primary key values by any integral data type

by Steve Ebersole (JIRA)

Allow consistent handling of numeric primary key values by any integral data type --------------------------------------------------------------------------------- Key: HHH-4905 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4905 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.x Currently Hibernate generally supports short, integer, long. For certain we should support BigInteger. BigDecimal (ensuring a zero scale) would be nice too. -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (METAGEN-22) Handle map-key-class in xml configuration

by Hardy Ferentschik (JIRA)

Handle map-key-class in xml configuration ----------------------------------------- Key: METAGEN-22 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-22 Project: Hibernate StaticMetamodel Generator Issue Type: Bug Affects Versions: 1.0.0-Beta-3 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.0.0-Beta4 -- 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, 10 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-283) Remove the legacy module from the main aggregator

by Hardy Ferentschik (JIRA)

Remove the legacy module from the main aggregator ------------------------------------------------- Key: HV-283 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-283 Project: Hibernate Validator Issue Type: Task Components: build Affects Versions: 4.0.2.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.1.0 Having the current setup causes some problems during SNAPSHOT deploy and really we don't want to push a legacy validator snapshot each time we deploy the other stuff. -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-979) Merge operation should retain existing identifiers

by Chris Wilson (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-979?page=co... ] Chris Wilson commented on HHH-979: ---------------------------------- I would also appreciate having a way to merge an object without losing its identifier. Currently I have to check whether it's in the database first, and then either save() or merge() depending on the result. Please could someone explain why merge() works this way, in more than one word? Thanks. > Merge operation should retain existing identifiers > -------------------------------------------------- > > Key: HHH-979 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-979 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.0.5 > Reporter: Aleksei Valikov > Priority: Minor > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Currently, merge(...) operation does not retain existing object identifiers. > Here's a demonstrating test case: > public void testIt() throws Exception { > final A a1 = new A(); > final B b1 = new B(); > a1.setId("A"); > a1.setB(b1); > a1.setD("d1"); > b1.setId("B"); > b1.setC("c1"); > save(a1); > > final A a2 = new A(); > final B b2 = new B(); > a2.setId("A"); > a2.setB(b2); > a2.setD("d2"); > b2.setId("B"); > b2.setC("c2"); > save(a2); > > final A a3 = load("A"); > > assertEquals(a3.getD(), a2.getD()); > assertEquals(a3.getB().getC(), a2.getB().getC()); > } > > public void save(A a) > { > final Session s = openSession(); > final Transaction t = s.beginTransaction(); > s.merge(a); > t.commit(); > s.close(); > } > > public A load(String id) > { > final Session s = openSession(); > final A a = (A) s.get(A.class, id); > s.close(); > return a; > } > load("A") returns null since merged objects have newly generated identifiers. Moreover, we get two entities persisted in the DB, not one: > INSERT INTO B VALUES('4028e4fc067e203f01067e2042690001','c1') > INSERT INTO A VALUES('4028e4fc067e203f01067e2042790002','4028e4fc067e203f01067e2042690001','d1') > COMMIT > INSERT INTO B VALUES('4028e4fc067e203f01067e2042e60003','c2') > INSERT INTO A VALUES('4028e4fc067e203f01067e2042e60004','4028e4fc067e203f01067e2042e60003','d2') > COMMIT > I think a more sensible behaviour is to retain identifiers. This can be achieved with a one-line code patch. > Before DefaultMergeEventListener.entityIsDetached(...) calls entityIsTransient(), it should set event.requestedId: > // .... > Serializable id = event.getRequestedId(); > if ( id == null ) { > id = persister.getIdentifier( entity, source.getEntityMode() ); > } > else { > //TODO: check that entity id = requestedId > } > final Object result = source.get(entityName, id); > if ( result == null ) { > //TODO: we should throw an exception if we really *know* for sure > // that this is a detached instance, rather than just assuming > //throw new StaleObjectStateException(entityName, id); > event.setRequestedId(id); > > // we got here because we assumed that an instance > // with an assigned id was detached, when it was > // really persistent > return entityIsTransient(event, copyCache); > } > // ... > This results in following DB operations: > INSERT INTO B VALUES('B','c1') > INSERT INTO A VALUES('A','B','d1') > COMMIT > DELETE FROM B WHERE ID='B' > INSERT INTO B VALUES('B','c2') > DELETE FROM A WHERE ID='A' > INSERT INTO A VALUES('A','B','d2') > COMMIT > At the moment, I've implemented is as my own listener, but would like in any case to know your opinion. > Anyways, something like MergeMode (analogous to ReplicationMode) would be also nice to have. -- 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, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4906) Collection incorrectly populated after LEFT_JOIN query with restriction on child

by Viliam Ďurina (JIRA)

Collection incorrectly populated after LEFT_JOIN query with restriction on child -------------------------------------------------------------------------------- Key: HHH-4906 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4906 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.3.1 Environment: Hibernate 3.3.1, but first encountered this but over a year ago. Database is Oracle 10g, but think it is DB-independent. Reporter: Viliam Ďurina Attachments: testcase.zip If you have two classes in one to many relationship (call them parent and child) and query the parent class with left-joined child with a restriction on a field of the child class, then the parent class's children collection is incorrectly initialized with a children list filtered by that restriction. Seems as incorrect optimization: Hibernate thinks the children collection is complete and initializes it from the query and caches it. If you replace LEFT_JOIN with INNER_JOIN, it works: the children collection is initialized in the moment it is first accessed by a separate query. But actually, in this case it has nothing to do with LEFT or INNER join, but with restrictions on the children association. See attached test case: run the Test class and see, that the children collection has only one item instead of three. Replace left join with inner and see that it works. -- 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, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2010