October 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2894) want to insert data having characters in any language (Indic, japanese, fiench) in MS SQL Server

by manohar (JIRA)

want to insert data having characters in any language (Indic, japanese, fiench) in MS SQL Server ------------------------------------------------------------------------------------------------- Key: HHH-2894 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2894 Project: Hibernate3 Issue Type: New Feature Components: query-hql Environment: windows Reporter: manohar am trying to insert data having Japanese kanji's into Micosoft SQL Server. I am doing this through Hibernate 3.0. I am not being able to do 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

17 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1718) Have multiple bag fetches revert to subselect fetching for all but one of the bags

by Geoffrey De Smet (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718?page=c... ] Geoffrey De Smet commented on HHH-1718: --------------------------------------- Using sets instead of bags leads to cartesian products being fetched. I've just tried switching to sets instead of bags, and although the query now executes, it's terrible on a medium to large dataset as it creates a cartesian product. Reverting to subselect for parallel collections would indeed fix that too and could actually be a lot better for multiple sets too. > Have multiple bag fetches revert to subselect fetching for all but one of the bags > ---------------------------------------------------------------------------------- > > Key: HHH-1718 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718 > Project: Hibernate3 > Issue Type: Improvement > Components: core, query-criteria, query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: hql+collection > > Attachments: hibernate_eksempel.zip > > > Follow on to HHH-1413. Multiple bag fetches were simply disallowed as the resolution to that particular case in the interest of working around that issue. > The correct longer term solution is to not fetch all the bags at once, ideally reverting to subselect fetching for all but one of the bags. -- 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

17 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1665) Assert the class for a Criteria is mapped

by Daniel Campagnoli (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1665?page=c... ] Daniel Campagnoli updated HHH-1665: ----------------------------------- Attachment: test case.zip > Assert the class for a Criteria is mapped > ----------------------------------------- > > Key: HHH-1665 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1665 > Project: Hibernate3 > Issue Type: Improvement > Components: query-criteria > Affects Versions: 3.1.3 > Reporter: Daniel Campagnoli > Priority: Minor > Attachments: test case.zip > > Original Estimate: 5 minutes > Remaining Estimate: 5 minutes > > In SessionImpl it would be handy if when getting the results for a criteria query it checked to see if the class is mapped and failed fast, as it currently silently returns an empty list. I ran into this problem because we have multiple session factories with different class mapped and from one DAO i tried to query a class that wasnt mapped in the SessionFactory being used. Could also happen if you accidently put the wrong class or added the wrong import for a class. > SessionImpl.java > public List list(CriteriaImpl criteria) throws HibernateException { > errorIfClosed(); > checkTransactionSynchStatus(); > String[] implementors = factory.getImplementors( criteria.getEntityOrClassName() ); > int size = implementors.length; > + if(size == 0) > + throw new HibernateException(criteria.getEntityOrClassName() + " is not mapped"); -- 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

17 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2864) Merging a detached instance with a new child in a unidirectional one-to-many association fails if the parent was previously loaded as a proxy

by Carl-Eric Menzel (JIRA)

Merging a detached instance with a new child in a unidirectional one-to-many association fails if the parent was previously loaded as a proxy --------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2864 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2864 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5, 3.1.3 Environment: Tested with Hibernate 3.1.3 and 3.2.5 on HSQL and Oracle 9, using JDK 1.4 and 1.6. The behavior is the same in each case. Reporter: Carl-Eric Menzel Attachments: ProxyMergeTest.zip Given a class One and a class Many with a unidirectional one-to-many relationship. I'm getting a PropertyValueException: "not-null property references a null or transient value: test.Many._toManyBackref" when merging a detached "One" instance which contains a new "Many" instance if and only if the "One" was previously loaded as a proxy in the same transaction. The meat of the problem: // create new One One one = new One(); one.setOneOther(new One()); session.save(one); commitAndGetNewSession(); /* * load saved instance as a proxy, but do not use it. we could use get() so we wouldn't get a proxy, but a real-world * application might have only loaded this instance transitively as a proxy before merging a detached instance, so this is a * real problem. */ Object proxyWeDontUse = session.load(One.class, new Integer(one.getId())); assertTrue(proxyWeDontUse instanceof HibernateProxy); // use detached instance and add a Many one.getToMany().add(new Many()); // merge the detached instance. this should work, but doesn't. the backref-getter doesn't correctly // find the parent object of the new Many, because the copyCache/mergeMap only contains the proxy loaded // above, but the entityEntries in PersistenceContext contain the raw unproxied object. session.merge(one); In this simplified testcase I explicitly load the proxy. In our actual scenario, the One is loaded transitively as a child of yet another parent object - usually as a proxy. We need to load this to perform some authorization checks before we can actually merge the incoming detached One instance. This leads to the situation of having the proxy first and only then merging. As far as I understand the documentation, this *should* work. I spent quite some time getting to the bottom of this - mostly debugging through the MergeEventListener. I found this: DefaultMergeEventListener uses Session.get() to load the persistent instance when merging a detached one. get() returns the proxy that was previously created. DefaultMergeEventListener then stores this returned proxy as the value of an entry in the copyCache. Later the backref-getter gets the actual persistent instance from the PersistenceContext and uses this to look for the detached instance in the mergeMap (which is the inverted copyCache, if I understood that correctly). But this only returns null, since the only key it can see is the *proxy* that was put as a value into the copyCache. Thus the backref-getter can't find its backref, leading to the exception. Proposed solution: Store the persistent instance in the copyCache instead of the proxy, or do some dereferencing magic when looking for the backref. I can't judge that though - all I know about this right now comes from several hours of serious debugging. I'm attaching an almost ready-to-use testcase as a zipped Eclipse project. Sources and config are in src/, the lib/ directory contains a hsqldb.jar which I used for fast testing. Simply add the required Hibernate jars and run the MergeUnidirectionalOneToManyTest. We currently use Hibernate 3.1.3 in production, but the problem occurs with 3.2.5 as well. A patched 3.1 release would be the best for us, but I'm not sure whether that is possible. Thanks! Carl-Eric Menzel Senacor Technologies AG -- 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

17 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2559) http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd needs to be updated

by Brian Bohl (JIRA)

http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd needs to be updated ------------------------------------------------------------------------------ Key: HHH-2559 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2559 Project: Hibernate3 Issue Type: Task Affects Versions: 3.2.2 Reporter: Brian Bohl Priority: Minor Looks like the hibernate-mapping-3.0.dtd on sourceforge needs to be updated. Specifically I am getting a validation error on the check attribute for sql-update but I am sure that is not the only difference. Obviously a workaround is to reference the dtd included in the hibernate3.jar, but it would be nice the have the latest version published. -- 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

17 years, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2857) schemaSupport for HSQLDialect remote connections doesn't work

by Carlo de Wolf (JIRA)

schemaSupport for HSQLDialect remote connections doesn't work ------------------------------------------------------------- Key: HHH-2857 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2857 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.4.sp1 Environment: AS 5.0 rev 65579 Reporter: Carlo de Wolf Using a remote DataSource on an (in memory) HSQLdb leads into the HHH-608 issue. The HSQLDialect only enabled schemaSupport if schemaManager is defined in org.hsqldb.Database. This class is not available locally, since I'm using a remote data source. Workaround: Put hsqldb.jar on my classpath. Is a depependency of EJBTHREE-1050. -- 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

17 years, 2 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2892) skip up-to-date checks of query cache for natural-id only if immutable

by Steve Ebersole (JIRA)

skip up-to-date checks of query cache for natural-id only if immutable ---------------------------------------------------------------------- Key: HHH-2892 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2892 Project: Hibernate3 Issue Type: Bug Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6, 3.3 Currently we skip the up-to-date checks for query cache entries when the query is a natural-id lookup. The reason being to avoid the database hit due to the (potential) invalidation caused by changes to the entity. However, that is not correct behavior if the mutable natural key itself changed. This skipping should be limited to the case of immutable natural ids. -- 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

17 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-84) No ConstraintViolationException thrown with HSQL database

by Baptiste MATHUS (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-84?page=com... ] Baptiste MATHUS commented on HHH-84: ------------------------------------ Hi, I found this problem with every HSQL DB version. I'm logging it here, though I think it might rather be a problem in the SQLException thrown by the HSQLDB engine. In fact, I just tested many versions of HSQLDB with a testcase (I tested 1.7.3.3 and many 1.8.0.x : 1.8.0.7 for example). The problem is that Hibernate can correctly wrap the exception in a ConstraintViolationException since the SQLException thrown by HSQLDB has an Sqlcode=0 and SqlState is null ! (In my case, this is a foreign key constraint, I'm attaching the testcase). So, a bug in the hsql jdbc driver, not in hibernate, I guess. Anyone confirm this? > No ConstraintViolationException thrown with HSQL database > --------------------------------------------------------- > > Key: HHH-84 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-84 > Project: Hibernate3 > Issue Type: Bug > Components: core > Environment: Hibernate version:3.0-beta1 > Database:HSQL1.7.2 > Reporter: Marcel Schroer > Assignee: Emmanuel Bernard > Priority: Minor > Fix For: 3.0 beta 2 > > > When a unique constraint violation is thrown by the HSQL database > (java.sql.SQLException: Unique constraint violation: SYS_CT_171 in statement), the SQLException is wrapped in a GenericSQLException instead of the ConstraintViolationException that I expected. -- 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

17 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2302) ArrayIndexOutOfBoundsException in AbstractScrollableResults

by Markus Heiden (JIRA)

ArrayIndexOutOfBoundsException in AbstractScrollableResults ----------------------------------------------------------- Key: HHH-2302 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2302 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0, Oracle 9.2 Reporter: Markus Heiden Attachments: hibernate.zip When using scrollable result sets on sql queries, the array of column types in AbstractScrollableResults has always the length zero. So all operations which do type checking fail, e.g. #getInteger(int col). Test case for this problem is attached. Stacktrace of failure in this test case: java.lang.ArrayIndexOutOfBoundsException: 0 at org.hibernate.impl.AbstractScrollableResults.getFinal(AbstractScrollableResults.java:126) at org.hibernate.impl.AbstractScrollableResults.getInteger(AbstractScrollableResults.java:208) at hibernate.scroll_types.Test.main(Test.java:30) -- 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

17 years, 3 months

4
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-1368) Transaction Manager LookUP class for Apache Geronimo Application server

by Jimmy Wan (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1368?page=c... ] Jimmy Wan commented on HHH-1368: -------------------------------- Has there been any update on this? > Transaction Manager LookUP class for Apache Geronimo Application server > ----------------------------------------------------------------------- > > Key: HHH-1368 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1368 > Project: Hibernate3 > Issue Type: New Feature > Components: core > Affects Versions: 3.0.5 > Environment: All versions, All Database platform > Reporter: Rakesh Ranjan > Priority: Minor > > Hibernate provides TransactionManager Lookup class for most of the J2EE application servers like Bea Weblogic, IBM Websphere, JBoss, Orion, Jrun. But there is no TransactionManager lookup class for Apache Geronimo Application server. Apache Geronimo is an emerging opensource J2EE application server. So we need to provide a TransactionManager lookup class for Apache Geronimo. -- 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

17 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2007