February 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-338) ScrollableResults initial position not coherent to core Hibernate

by Sanne Grinovero (JIRA)

ScrollableResults initial position not coherent to core Hibernate ----------------------------------------------------------------- Key: HSEARCH-338 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-338 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.1.0.GA Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 3.1.1 The javadoc for interface ScrollableResults reads: "Go to a location just before first result (this is the initial location)" but Search's initial position is at the first result instead. -- 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
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3642) EJB3 inheritance strategy TABLE_PER_CLASS does not work on HSQLDB

by Wolfgang Knauf (JIRA)

EJB3 inheritance strategy TABLE_PER_CLASS does not work on HSQLDB ----------------------------------------------------------------- Key: HHH-3642 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3642 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: JBoss 5.0GA, Java 1.6, Hypersonic 1.8.0.8 Reporter: Wolfgang Knauf Attachments: InheritanceTablePerClass.ear I use an EJB3 entity bean with inheritance strategy "TABLE_PER_CLASS": @Entity @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) public abstract class Base implements Serializable { ... When loading a list of base classes, all subclass fields are null. The union subclause in the query does not work on HSQLDB. Attached is a full EJB sample, runnable on JBoss 4.2/5.0 (project export of Eclipse 3.4/WebTools 3.0 with sources). After deploying, it can be tested by browsing to http://localhost:8080/InheritanceTablePerClassWeb/ See this output: ... Loading ALL Item: Child 1, child field 1: null Item: Child 2, child field 2: null Item: Child 3, child field 3: Field of Child3 ... Here, all childs are loaded. The fields of type "Child1" and "Child2" are null, fields of type "Child3" are filled. This is probably a duplicate of http://opensource.atlassian.com/projects/hibernate/browse/HHH-2920 The described workaround to change all NULL expressions to "cast (null as VARCHAR)" results in a working query, but I see no chance to pre-configure this query in the entity manager. I created another bug, because the impact is different (it breaks a feature of EJB3), and so I consider severity to be higher. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-41) Support BeanInfo implementation to receive property names

by Emmanuel Bernard (JIRA)

Support BeanInfo implementation to receive property names --------------------------------------------------------- Key: BVAL-41 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-41 Project: Bean Validation Issue Type: Improvement Components: spec-general Reporter: Emmanuel Bernard Michael - Why section 3.1.2 requires properties to follow the JavaBeans naming convention? In many non-English speaking countries (and projects with ridiculous managers/code standards), other prefixes are used and proper BeanInfo implementations are supplied. Although it is not pretty at all, since they are following the JavaBean spec, I don't think Bean Validation shouldn't work out-of-the-box for them; Emmanuel I reused the Java Persistence wording actually and I explicitly reference the Introspector class. Do people think we should be more cautious here? Speaking for France, I've never seen a project bothering about get/is/set and BeanInfo. People happily used frenglish: getCafeAuLait() Actually I've never seen anybody from the server side bothering about BeanInfos ;) Michael I've got an interesting case for that one: in some JVM languages, another standard is used to represent properties. Let's take, for instance, Scala. In Scala, one could write a bean like: @BeanInfo class Person(var id : Long, var name : String, var surname : String) Scala already maps vars as properties creating a private var, a public getter method named like the var and a setter like var_=. Something like: private var _id : Long def id = _id def id_=(newId: Long) = _id = newId that would translate to Java methods id and id_$eq (since = cannot be used in method names). So, when one use @BeanInfo, a proper BeanInfo subclass is generated by the compiler providing that mapping. Given how popular JVM languages are getting, not following a spec in another one and causing property support in those languages to fail to work doesn't seem nice. BTW, please let the JPA EG know about his as well. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-82) Migrate ant build to maven2

by Hardy Ferentschik (JIRA)

Migrate ant build to maven2 --------------------------- Key: HSEARCH-82 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-82 Project: Hibernate Search Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Switch from ant to maven2 as build tool. Initally just try to build HSearch with maven. Once it works we can see if we can extract a common HibernateExt parent pom. -- 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

4
10
0 / 0

[Hibernate-JIRA] Créée: (HHH-2060) To be able to use <generator> with <composite-id>

by Xavier Brénuchon (JIRA)

To be able to use <generator> with <composite-id> ------------------------------------------------- Key: HHH-2060 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2060 Project: Hibernate3 Type: Improvement Versions: 3.2.0.cr4 Environment: Hibernate 3.x Reporter: Xavier Brénuchon Hello, This is the continuation of HB-389 We develop an application which has very strong need for performance with several tens of million recordings. Partitioning is a need. So for that, I use <composite-id>. But my primary key is not a natural key, but a real technical key : - column of partitioning for optimization of the data base - column of technical id So I need to have a generator, for exemple : <composite-id name="id" class="IdPartition"> <key-property name="org" type="string" column="ORG"/> <key-property name="id" type="long" column="ID"/> <generator class="fr.test.xavier.IdPartitionGenerator"> <param name="table">TAB_SEQ</param> <param name="column">LAST</param> </generator> </composite-id> The good news is that Hibernate can use that (HB-389). In fact, it is enough to modify the DTD to authorize <generator> in <composite-id> and it is all. The current code of Hibernate manages it very well. Is it possible that Hibernate is enriched by this functionality? -- 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

7
17
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-301) Refactor JMSMasterTest and JMSSlaveTest

by Hardy Ferentschik (JIRA)

Refactor JMSMasterTest and JMSSlaveTest --------------------------------------- Key: HSEARCH-301 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-301 Project: Hibernate Search Issue Type: Improvement Components: build Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik The aim is to get rid of the embedded jboss server for the test. This environment is not supported and creates amongst others problems with CP builds. The embedded server is only used for testing the JMS clustering functionality. This functionality could be replaced with ActiveMQ - http://activemq.apache.org/how-to-unit-test-jms-code.html. -- 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
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-332) documentation error p.11: org.hibernate.Query should be javax.persistence.Query

by Yev Belman (JIRA)

documentation error p.11: org.hibernate.Query should be javax.persistence.Query --------------------------------------------------------------------------------- Key: HSEARCH-332 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-332 Project: Hibernate Search Issue Type: Bug Components: documentation Affects Versions: 3.1.0.GA Environment: Core 3.3.1.GA Search 3.1.0.GA Reporter: Yev Belman JPA example on page 11 is wrong: // wrap Lucene query in a org.hibernate.Query org.hibernate.Query hibQuery = fullTextEntityManager.createFullTextQuery(query, Book.class); It should read: javax.persistence.Query hibQuery = fullTextEntityManager.createFullTextQuery(query, Book.class); -- 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
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-326) Drop support for IndexReader usage to update indexes.

by Sanne Grinovero (JIRA)

Drop support for IndexReader usage to update indexes. ----------------------------------------------------- Key: HSEARCH-326 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-326 Project: Hibernate Search Issue Type: Task Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.1.1 in Workspace, remove "getIndexReader()" and all references to an IndexReader. In LuceneWorkDelegate and all implementations, remove "performWork(LuceneWork work, IndexReader reader)" Simplify PerDPQueueProcessor as no "best strategy choice" makes sense anymore. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-284) Lucene locks left around in application restart/crash

by sam doyle (JIRA)

Lucene locks left around in application restart/crash ----------------------------------------------------- Key: HSEARCH-284 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-284 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.0.1.GA Reporter: sam doyle In a case where an application restarts, crashes, gets killed etc. if there is an existing Lucene lock it will not be removed on the application restart. As a result of this the application itself can be severely impacted. After encountering this particular issue and needing to manually remove the lock to resolve the problem I did some searching. It appears this situation is somewhat common and the use of NativeFSLockFactory was the suggested solution. Since I don't see where this particular option is configurable with Hibernate Search I have opened this request. -- 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

4
6
0 / 0

[Hibernate-JIRA] Created: (HV-116) Write tests for metadata api

by Hardy Ferentschik (JIRA)

Write tests for metadata api ---------------------------- Key: HV-116 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-116 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Hardy Ferentschik Fix For: 4.0.0.GA This includes tests of all the *Descriptor classes - ElementDescriptor, BeanDescriptor, PropertyDescriptor, ConstraintDescriptor -- 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

1
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2009