March 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-459) Update quickstart archetype

by Sanne Grinovero (JIRA)

Update quickstart archetype --------------------------- Key: HSEARCH-459 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-459 Project: Hibernate Search Issue Type: Task Affects Versions: 3.2.0.Beta1 Reporter: Sanne Grinovero Assignee: Hardy Ferentschik Fix For: 3.2.0.Beta2 -- 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, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-470) Separate indexes by field (foreign key)

by Dobes Vandermeer (JIRA)

Separate indexes by field (foreign key) --------------------------------------- Key: HSEARCH-470 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-470 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.1.1.GA Reporter: Dobes Vandermeer Priority: Minor In our system we always constrain searches by a particular foreign key so that the search only returns results that are related to the object being viewed at the time. I think it would greatly decrease the memory usage of our queries if we could actually store a separate FSDirectory for each value of this key. As an example, consider a multi-user email system like GMail where users can only access their own email but are all using the same web application. In this case it would be useful to have a separate search index for each user rather than one large shared one because any given search will always look only at the records associated with that user, yet it will still allocate a potentially enormous "norms" array with one entry for every single email in the entire system. With this improvement it would be possible to have smaller indexes and smaller norms in systems where despite sharing the same hibernate configuration and session factory, searches are always tied to a particular foreign key. Looking at the sharding system I can see that a sharding strategy wouldn't do the trick because it always queries all the shards but in this case we want queries to apply to only one shard. I think it is likely that there are many possible uses for this feature, as this use case seems to me like it would be fairly common. -- 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, 3 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-759) problem for mixxing setmaxresults and setlockmode

by Chad Moller (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-759?page=co... ] Chad Moller commented on HHH-759: --------------------------------- This seems to still be an issue in 3.2 > problem for mixxing setmaxresults and setlockmode > ------------------------------------------------- > > Key: HHH-759 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-759 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.0.2 > Environment: Client:windows2000 professional,jre1.4.2, oracle8client,eclipse3.1-RC3,hibernate-tools 3.0 alpha4a,JBossIDE1.5M1 > Server:Solaris 2.8, oracle 8.1.7 > Reporter: johnhua > Priority: Minor > > there is a problem for mixxing setmaxresults and setlockmode. > the problem is that "ORA-00904: invalid column name". > The error info is as the below: > Hibernate: select * from ( select idmapp0_.RI as col_0_0_ from PCTMNGT.IDMAP_P idmapp0_ where idmapp0_.STATUS=? ) where rownum <= ? for update of idmapp0_.RI > 14:21:54,076 DEBUG AbstractBatcher:AbstractBatcher.java:365 - preparing statement > 14:21:54,082 DEBUG AbstractBatcher:AbstractBatcher.java:285 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) > 14:21:54,083 DEBUG AbstractBatcher:AbstractBatcher.java:403 - closing statement > 14:21:54,090 WARN JDBCExceptionReporter:JDBCExceptionReporter.java:71 - SQL Error: 904, SQLState: 42000 > 14:21:54,091 ERROR JDBCExceptionReporter:JDBCExceptionReporter.java:72 - ORA-00904: invalid column name > The source code is as the below: > //query an unused emid for new tone > query = av_session.createQuery("select v_idmap from IdmapP as v_idmap where v_idmap.status=:v_status"); > query.setCharacter("v_status",EMID_STATUS.UNUSED.charValue()); > query.setMaxResults(1); > query.setLockMode("v_idmap",LockMode.UPGRADE); > it = query.iterate(); > if( !it.hasNext() ) > { > tx.rollback(); > lv_err = "addRing::doAddRingFile: no unused EMID for new tone in idmap. toneid="+av_tone; > throw new InterfaceErrException(lv_err,INTERFACE_RETCODE.SYSTEM_ERR); > } -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5014) Custom PropertyAccessor / illegal access to loading collection

by Stephan Sann (JIRA)

Custom PropertyAccessor / illegal access to loading collection -------------------------------------------------------------- Key: HHH-5014 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5014 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: Hibernate 3.3.2 GA, HSQLDB 2.0.0-rc8 Reporter: Stephan Sann I posted the problem on the Hibernate-forum (https://forum.hibernate.org/viewtopic.php?f=1&t=1003277) and got no answer. So I assume this is a bug. I wrote a custom PropertyAccessor {code} public class MyPropertyAccessor implements PropertyAccessor{code} with this code within the set-Method of the Setter: {code} public void set(Object target, Object value, SessionFactoryImplementor factory) throws HibernateException { try { if (((List) value) == null) { return; } List tempList = new ArrayList(); tempList.addAll((List) value); // ... more code here{code} What I get during runtime is a "LazyInitializationException: illegal access to loading collection" (Stacktrace see below.). IMHO Hibernate shouldn't give me an uninitialized value (AbstractPersistentCollection) into the set-method of the PropertyAccessor!? (Hibernate should assume that I want to do something with the collection before setting it to the entity!) If I don't got the concept of a PropertyAccessor completely wrong, the "set"-flow should work like this: 1.) (Hibernate-Core) Load the data from Database (completely*), transform it to a value of the matching type (e.g. List) and hand it over to the PropertyAccessor. 2.) (PropertyAccessor) Receive the (completely*) loaded and transformed value, do whatever modification is necessary and set the result to the entity. completely*: In case of FetchType.EAGER: Completely loaded / in case of FetchType.LAZY: "Ready to access". Correct me if I got something wrong here. BTW: The corresponding List-property of the entity is FetchType.EAGER: {code} @OneToMany (fetch = FetchType.EAGER) @Cascade ({CascadeType.ALL}) @JoinColumn(name="ParentId") @IndexColumn(name="ParentIndex") @AccessType(value="path.to.MyPropertyAccessor") private List<Foo> fooList;{code} (and the Hibernate-session should also be alive at the moment of the Exception) The stacktrace: org.hibernate.LazyInitializationException: illegal access to loading collection at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:363) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:108) at org.hibernate.collection.PersistentList.toArray(PersistentList.java:146) at java.util.ArrayList.addAll(ArrayList.java:472) at path.to.MyPropertyAccessor$BasicSetter.set(MyPropertyAccessor.java:71) at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:352) at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:232) at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3580) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:152) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877) at org.hibernate.loader.Loader.doQuery(Loader.java:752) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259) at org.hibernate.loader.Loader.loadEntity(Loader.java:1885) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:71) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:65) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3062) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:434) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:415) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:165) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:223) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:906) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:843) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:836) at org.springframework.orm.hibernate3.HibernateTemplate$1.doInHibernate(HibernateTemplate.java:519) at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:512) at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:506) // some more... -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5013) the previous select query should not to hold locks in TypeParameterTest#testSave

by Strong Liu (JIRA)

the previous select query should not to hold locks in TypeParameterTest#testSave -------------------------------------------------------------------------------- Key: HHH-5013 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5013 Project: Hibernate Core Issue Type: Bug Components: testsuite Affects Versions: 3.5.0-CR-2 Reporter: Strong Liu Assignee: Strong Liu Fix For: 3.5.0.Next Hi Strong Liu, I'm getting "lock timeout" in the org.hibernate.test.typeparameters.TypeParameterTest testSave test. Within testSave and testLoading a session and transaction is initiated to create a Widget object, persist it and then closed. A second session is started with a transaction to query the Widget attributes followed by a call to deleteData while this parent session holds physical database locks. Within the deleteData method a new session with its own transaction is created which waits for locks held by the parent resulting in a deadlock. I presume the test is expecting the previous select query not to hold locks? -- 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, 3 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-267) Enhance distribution jar to make it OSGi bundle

by Jaro Kuruc (JIRA)

Enhance distribution jar to make it OSGi bundle ----------------------------------------------- Key: HV-267 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-267 Project: Hibernate Validator Issue Type: Improvement Components: build Affects Versions: 4.0.1.GA Reporter: Jaro Kuruc Hi, please consider enhancing validator's maven build to produce OSGi compliant bundle by adding OSGi specific manifest headers. At the moment, there are 2 options to do that: 1. Felix Bundle Plugin http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html 2. SpringSource Bundlor http://static.springsource.org/s2-bundlor/1.0.x/user-guide/html/ch03s03.html Also, take a look at the bundle which has been produced by SpringSource http://www.springsource.com/repository/app/bundle/version/detail?name=com... -- 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, 3 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5012) Improvement for test EntityTest.java

by Stephan Palm (JIRA)

Improvement for test EntityTest.java ------------------------------------ Key: HHH-5012 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5012 Project: Hibernate Core Issue Type: Improvement Components: annotations Affects Versions: 3.5.0-CR-2 Reporter: Stephan Palm Priority: Minor The following tests could behave nicer on failures: testUniqueConstraint testColumnUnique The database which I am writing a dialect for has no unique constraint. When I execute those tests I get a RollbackException which is not the intended behavior. The test tries to give a nice failure message, {code} tx.commit(); fail( "unique constraints not respected" ); {code} but the later {code} finally { if ( tx != null ) tx.rollback(); s.close(); } {code} creates an Exception which masks the Failure. This could be avoided by adding a tx = null; {code} tx.commit(); tx = null; fail( "unique constraints not respected" ); {code} -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5010) org.hibernate.test.hql.CriteriaHQLAlignmentTest.testCriteriaAggregationReturnType() needs call flush before do the query

by Strong Liu (JIRA)

org.hibernate.test.hql.CriteriaHQLAlignmentTest.testCriteriaAggregationReturnType() needs call flush before do the query ------------------------------------------------------------------------------------------------------------------------ Key: HHH-5010 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5010 Project: Hibernate Core Issue Type: Bug Components: testsuite Affects Versions: 3.5.0-CR-2 Reporter: Strong Liu Fix For: 3.5.0.Next this test falls on some DBs due to no insert sql be issued before the query -- 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, 3 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4946) org.hibernate.test.legacy.FooBarTests testLimit failure with Ingres

by Ray Fan (JIRA)

org.hibernate.test.legacy.FooBarTests testLimit failure with Ingres ------------------------------------------------------------------- Key: HHH-4946 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4946 Project: Hibernate Core Issue Type: Bug Components: testsuite Affects Versions: 3.5.0-Beta-4 Environment: Hibernate 3.5.0-Beta-4, Ingres 9.3.1 (int.lnx/106) Reporter: Ray Fan Priority: Minor Attachments: FooBarTest.svn.diff, IngresOffsetLimitTest.java, limit.zip Assertion failure during testLimit test in legacy testsuite. {noformat} <failure type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.hibernate.test.legacy.FooBarTest.testLimit(FooBarTest.java:1614) </failure> {noformat} According to the generated SQL queries the returned result set row count is 6. The behaviour of "first n" "offset m" is to move the starting row before applying the cardinality limit. I believe that test is assuming that the "offset m" is applied to the returned row set. -- 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, 3 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-458) Remove all deprecations from Lucene's 2.9 API usage

by Sanne Grinovero (JIRA)

Remove all deprecations from Lucene's 2.9 API usage --------------------------------------------------- Key: HSEARCH-458 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-458 Project: Hibernate Search Issue Type: Sub-task Reporter: Sanne Grinovero Assignee: Sanne Grinovero -- 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, 3 months

1
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2010