January 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSHARDS-52) Hibernate Shards not applying setMaxResults as a SQL LIMIT

by Max Ross (JIRA)

Hibernate Shards not applying setMaxResults as a SQL LIMIT ---------------------------------------------------------- Key: HSHARDS-52 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-52 Project: Hibernate Shards Issue Type: Bug Components: engine Reporter: Max Ross Assignee: Max Ross Fix For: 3.0.0 http://forum.hibernate.org/viewtopic.php?p=2374359&sid=b337277456949beac5... -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-136) CachingWrapperFilter does not cache

by Tobias Hill (JIRA)

CachingWrapperFilter does not cache ------------------------------------ Key: HSEARCH-136 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-136 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.0.0.GA Reporter: Tobias Hill See http://forum.hibernate.org/viewtopic.php?p=2369054#2369054 The CachingWrapperFilter uses the reader instance as a key for the caching. In HibernateSearch readers seems to be wrapped into a MultiReader which by itself is new each time and thus defeat the cache purpose. -- 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, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-147) Allow projection of Lucene DocId

by Christian Wiedmann (JIRA)

Allow projection of Lucene DocId -------------------------------- Key: HSEARCH-147 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-147 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.0.0.GA Reporter: Christian Wiedmann Priority: Minor It would be nice if the Lucene docid could be projected from a query so that TokenSources.getAnyTokenStream(IndexReader reader, int docId, String field, Analyzer analyzer) can be used. This function has the advantage that it extracts the token stream from Lucene without reparsing if it is able to. If it is unable, it will reparse the stored field with the given analyzer. -- 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, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-125) Add support for fields declared by interface or unmapped superclass

by Igor Stroh (JIRA)

Add support for fields declared by interface or unmapped superclass ------------------------------------------------------------------- Key: HSEARCH-125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-125 Project: Hibernate Search Issue Type: Improvement Components: engine, mapping Affects Versions: 3.0.0.GA Reporter: Igor Stroh Priority: Minor Attachments: IndexedTarget.patch If an @IndexedEmbedded field is delcared by an interface or a unmapped superclass, there is no way hibernate-search can resolve the concrete class (compare to org.hibernate.annotations.Target or the targetEntity parameter for @*To* annotations). The attached patch solves this issue by introducing a IndexedTarget annotation which, much like @Target, expects the mapped class as its single parameter. See test/org/hibernate/search/test/embedded/ changes for a simple example. This issue was first exmplained in http://forum.hibernate.org/viewtopic.php?p=2366118 -- 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, 10 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-130) Should provide better log infos (on the indexBase parameter for the FSDirectoryProvider)

by Eric Perrocheau (JIRA)

Should provide better log infos (on the indexBase parameter for the FSDirectoryProvider) ---------------------------------------------------------------------------------------- Key: HSEARCH-130 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-130 Project: Hibernate Search Issue Type: Improvement Components: directory provider Affects Versions: 3.0.0.GA Reporter: Eric Perrocheau Priority: Minor When tracking bugs due to invalid directories names for the FSDirectoryProvider, it could be nice if the logs did inform more on Hibernate Search behaviour, or help highlight some problem. E.g., if the indexes already exist on disk, under windows vista, and we provide the directory name with erroneous trailing spaces in the configuration file : Hibernate Search run half well : the only problem is that it clears the old indexes on initializing the FSDirectoryProvider since it didn't find the directory with the trailing spaces. After that, it doesn't seem to mind the wrong directory name since it finds and uses the good one. Is suppose we could expect Hibernate Search to tell that something is happening and why, in fact, without having to go in the code with the debugger to find that the trailing spaces are sometimes a problem and sometimes not. (this improvement was asked for on http://forum.hibernate.org/viewtopic.php?t=980567 ) -- 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, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-126) Better diagnostic when Search index directory cannot be opened

by Ian (JIRA)

Better diagnostic when Search index directory cannot be opened -------------------------------------------------------------- Key: HSEARCH-126 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-126 Project: Hibernate Search Issue Type: Patch Affects Versions: 3.1.0 Environment: Found in version deployed inside JBoss-Seam 2.0.0.CR2, but affects more Reporter: Ian Priority: Minor Attachments: DirectoryProviderHelper.diff When Search cannot create the index directory, the message in the Exception thrown by o.h.s.util.DirectoryProviderHelper.java contains the path as entered by the original user; it is often the case that this will be deployed inside an application server and the user will not know the correct path that is in need of permissions repair because of the way e.g., JBoss-AS creates randomly named subdirectories under e.g., server/default/deploy. This just changes the message to include the full path if the user gave an absolute path. -- 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, 10 months

2
5
0 / 0

[Hibernate-JIRA] Created: (ANN-693) org.hibernate.engine.query.sql.NativeSQLQueryScalarReturn not serializable

by Eugeniusz Neugebauer (JIRA)

org.hibernate.engine.query.sql.NativeSQLQueryScalarReturn not serializable -------------------------------------------------------------------------- Key: ANN-693 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-693 Project: Hibernate Annotations Issue Type: Bug Environment: jboss 4.2.2, HB 3.2.5 Reporter: Eugeniusz Neugebauer In my domain class I've NamedNativeQuery: @SqlResultSetMappings({@SqlResultSetMapping(name = "uir_suma_zbiorow_result", columns = @ColumnResult(name = "result"))}) @NamedNativeQueries({@NamedNativeQuery(name = "uir.uir_suma_zbiorow", query = "select uir_suma_zbiorow(:var1, :var2, :var3) as result", resultSetMapping = "uir_suma_zbiorow_result")}) During build session factory on jboss i have Exception: Caused by: javax.naming.CommunicationException [Root exception is java.io.NotSerializableException: org.hibernate.engine.query.sql.NativeSQLQueryScalarReturn] at org.jnp.interfaces.NamingContext.bind(NamingContext.java:618) at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552) at org.jboss.util.naming.Util.bind(Util.java:102) at org.jboss.util.naming.Util.bind(Util.java:89) at pl.computerland.syriusz.std.hibernate.jmx.Hibernate2.bind(Hibernate2.java:429) -- 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, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3084) DialectFactory.java doesn't map the IngresDialect

by Michael Leo (JIRA)

DialectFactory.java doesn't map the IngresDialect ------------------------------------------------- Key: HHH-3084 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3084 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha Environment: Hibernate 3.x and frameworks based on the Spring Framework, like Grails Reporter: Michael Leo Attachments: DialectFactory.java.patch Although Hibernate ships with an Ingres dialect org.hibernate.dialect.IngresDialect it can't be found by the dialect factory org.hibernate.dialect.DialectFactory Although most tools can be forced to use the proper dialect, there is a circumstance in Grails where there is no way to specify the correct Hibernate dialect for a custom data source. The patch is pretty straightforward. I've attached the output of "svn diff" from the root of the latest branch. Hope this makes sense, Mike Leo $ svn diff Index: src/org/hibernate/dialect/DialectFactory.java =================================================================== --- src/org/hibernate/dialect/DialectFactory.java (revision 14289) +++ src/org/hibernate/dialect/DialectFactory.java (working copy) @@ -112,6 +112,9 @@ private static final Map MAPPERS = new HashMap(); static { // TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place + MAPPERS.put( "Ingres", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) ); + MAPPERS.put( "ingres", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) ); + MAPPERS.put( "INGRES", new VersionInsensitiveMapper( "org.hibernate.dialect.IngresDialect" ) ); MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) ); MAPPERS.put( "DB2/NT", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) ); MAPPERS.put( "DB2/LINUX", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) ); $ -- 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, 10 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2957) ActionQueue Insertion sort performance degrades exponentially

by Jay Erb (JIRA)

ActionQueue Insertion sort performance degrades exponentially ------------------------------------------------------------- Key: HHH-2957 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2957 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Reporter: Jay Erb Attachments: ActionQueue.java, NewInsertActionSorter.java The algorithm for sorting entity insertions performs poorly for when flushing large numbers of entity insertions. There are a few reasons for this: 1. The sort used linear searches over lists which required nested looping. 2. ArrayLists were used to hold the insertion events. ArrayLists give good performance for looping but they have a couple of significant drawbacks: a. Whenever a new item is added to the list, the list is rebuilt with the new size, which causes another loop over all the entries in the list. b. Since it is an array, a contiguous block of memory must be found to hold the array. As the array get large, it gets harder and harder to find a contiguous block large enough. This causes the garbage collector to be run more often, which obviously reduces performance again. I changed the algorithm so that the product of the sort is exactly the same. The difference is that I used hashes for searches and LinkedLists for storing the insertions. The performance is linear. Attached are my changes. -- 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, 10 months

2
13
0 / 0

[Hibernate-JIRA] Commented: (ANN-401) @OrderBy does not work with inherited properties

by Dave Whittaker (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-401?page=co... ] Dave Whittaker commented on ANN-401: ------------------------------------ I'm curious as to why this would be so difficult. Could one not just check the metadata for the target object to see where the order by property is within the class hierarchy and then do an additional join to the table that represents the targets superclass? Ok, that was clearer in my head than it sounds when I re-read it. Basically, using the example above (with joined inheritance) why can't the location of propertyForOrderBy by determined to be class A (I'm assuming Hibernate already has this information available), which could result in the table for class A being joined during the query using the primary keys of A and B, then the order by would simply have to reference the table for A. Or am I completely off here....... > @OrderBy does not work with inherited properties > ------------------------------------------------ > > Key: ANN-401 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-401 > Project: Hibernate Annotations > Issue Type: Bug > Components: binder > Affects Versions: 3.2.0.cr1 > Environment: Hibernate 3.2, MySql 4, Windows XP > Reporter: Guido Laures > > Using an @OrderBy with an inherited property produces an SQL Exception. > Example: > @Entity > class Base { > ... > public int getPropertyForOrderBy(){ return propertytoOrderBy; } > ... > } > @Entity > @PrimaryKeyJoinColumn(name="a_id") > class A extends Base { > ... > } > @Entity > @PrimaryKeyJoinColumn(name="b_id") > class B extends Base { > ... > @OneToMany(mappedBy = "someProp", cascade = { CascadeType.ALL }) > @OrderBy("propertyToOrderBy") > public Set<A> getASet() { > return this.aSet; > } > ... > } > Thus, if A references a set of Bs and wants it to be ordered by a property of B's base class Base it crashes. The generated SQL string tries to find the property from the base class in the table of the inerited class (A) which fails. -- 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, 10 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 January 2008