[Hibernate-JIRA] Created: (HSEARCH-374) Timeout support for lucene searches
by Benjamin Gniza (JIRA)
Timeout support for lucene searches
-----------------------------------
Key: HSEARCH-374
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-374
Project: Hibernate Search
Issue Type: New Feature
Components: query
Reporter: Benjamin Gniza
Attachments: bit-TimeoutPatched-Hibernate-Search-1.0.1EXPERIMENTAL.zip
It would be nice to add support for the TimeLimitedCollector of Lucene (Versions 2.4.0 and above).
We needed that feature in our project within a week so we couldn't wait for a new official release and had to imlement it on our own.
Check out https://sourceforge.net/projects/timeoutpatchhib/ for our source (LGPL just as requested by hibernate).
I attached our current source code to the Jira issue. New versions will be published on sourceforge, please refer to https://sourceforge.net/projects/timeoutpatchhib/ for the most current one. The attached source only includes the code to support the TimeLimitedCollector.
We also have an experimental version which tries to find the reason of a BooleanQuery.TooManyClausesException within the offending user search term. For more information take a look at the sourceforge project.
Note: We didn't overide the query.setTimeout(int) method because we didn't know if this would have caused other side effects. So we created a method query.setTimeout(long).
Changed Methods:
- org.hibernate.search.FullTextQuery
-- +isSearchTimoutExceeded()
-- +setTimeout(long)
-- +getTimeout()
- org.hibernate.search.query.FullTextQueryImpl
-- getQueryHits(IndexSearcher, Integer)
-- +isSearchTimoutExceeded()
-- +setTimeout(long)
-- +getTimeout()
- org.hibernate.search.query.QueryHits
-- Constructors
-- scoreDoc(int)
-- updateTopDocs(int)
-- +getTopDocCollector(int)
-- +getHitCollectorForSearch(TopDocCollector)
-- +isTimeLimitExceeded()
--
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, 2 months
[Hibernate-JIRA] Created: (ANN-668) Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
by Clint Popetz (JIRA)
Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
------------------------------------------------------------------------------------------------
Key: ANN-668
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-668
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Hibernate 3.2.X, no database needed (happens during factory build before connecting to db)
Reporter: Clint Popetz
Attachments: propertyTypeExtractorBug.tar.gz
The following source:
@javax.persistence.Entity
public class TestEntity {
@javax.persistence.Id
public int Id;
public java.util.ArrayList<Object[]> badMethod() { return null; }
public static void main(String args[]) {
new org.hibernate.cfg.AnnotationConfiguration().addAnnotatedClass(TestEntity
.class).configure().buildSessionFactory();
}
}
will cause:
java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.toXType(JavaReflectionManager.java:164)^M
at org.hibernate.annotations.common.reflection.java.JavaXMethod.create(JavaXMethod.java:18)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.getXMethod(JavaReflectionManager.java:128)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethods(JavaXClass.java:114)
at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:214)
at org.hibernate.validator.ClassValidator.<init>(ClassValidator.java:133)
at org.hibernate.validator.event.ValidateEventListener.initialize(ValidateEventListener.java:91)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:356)
at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1304)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
Changing the return type to List<Object[]> avoids the bug.
Attached is a tgz of an ant-buildable project; typing "ant run" will illustrate the bug.
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-3873) DB2Dialect.getLimitString raise DB2 error message when called with limit=0
by Julien Kronegg (JIRA)
DB2Dialect.getLimitString raise DB2 error message when called with limit=0
--------------------------------------------------------------------------
Key: HHH-3873
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3873
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: DB2,
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/Branch...
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/Branch...
Reporter: Julien Kronegg
Priority: Minor
Executing a query called with setMaxResults(n) makes the underlying Hibernate code to call DB2Dialect.getLimitString.
While this is working fine in general case, the following database error is raised when setting the maximum number of results to zero:
SqlException: NUMBER 0 DIRECTLY SPECIFIED IN AN SQL STATEMENT IS OUTSIDE THE RANGE OF ALLOWABLE VALUES IN THIS CONTEXT (1, 2147483647)
This is due to the getLimitString method in classes DB2400Dialect and DB2390Dialect :
public String getLimitString(String sql, int offset, int limit) {
return new StringBuffer(sql.length() + 40)
.append(sql)
.append(" fetch first ")
.append(limit)
.append(" rows only ")
.toString();
}
When the limit parameter is set to zero, the fetch limit is appended, which explains why the error message occur.
Solution:
------------
When the limit is 0, there should be no "fetch first" instruction appended (as 0 is the general convention for "no limit"). The code would be:
public String getLimitString(String sql, int offset, int limit) {
+ if (limit==0) return sql;
return new StringBuffer(sql.length() + 40)
.append(sql)
.append(" fetch first ")
.append(limit)
.append(" rows only ")
.toString();
}
Workaround:
------------------
In order to avoid the error message, getLimitString(n) or setMaxResults(n) should be called with the 'newN' argument:
int newN = (n==0?Integer.MAX_VALUE:n);
Note: since the workaround is quite easy, I set the priority to "Minor"
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-2319) StatelessInterceptor
by Max Rydahl Andersen (JIRA)
StatelessInterceptor
--------------------
Key: HHH-2319
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2319
Project: Hibernate3
Type: New Feature
Components: core
Versions: 3.2.1
Reporter: Max Rydahl Andersen
It would make sense to have an Interceptor for StatelessSession to solve the following usecases:
Log/adjust SQL: onPrepareStatement
Proper entityname handling: instantiate/getEntity
Maybe also tx interaction: afterTransationBegin/beforeTransactionCompletion/afterTransactionCompletion
Technically it could be solved by just allowing to pass in a normal interceptor to a StatelessSession and just
document that the state oriented callbacks will not be called. Alternatively we can create a StatelessInterceptor that
only implement the releavant methods and wrap that instance into an internal Interceptor.
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-2007) Hibernate doesn't support optional one-to-one associations
by Andrei Iltchenko (JIRA)
Hibernate doesn't support optional one-to-one associations
----------------------------------------------------------
Key: HHH-2007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2007
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Reporter: Andrei Iltchenko
Hibernate doesn't properly support optional one-to-one associations, e.g. Person (0..1) -- (0..1) Passport.
The Hibernate books and reference all talk of two ways of mapping one-to-one associations:
1. using a many-to-one fk association with a unique constraint on the fk;
2. using a pk association.
the trouble with both of them is that they enforce the mandatory property of an association end, which sometimes is not desirable. The first way enforces the mandatory property with the uniqueness constraint on the fk, the other by using the fact that one table's pk is its fk.
I tried to see if I could adapt the 1st way of representing one-to-ones to
support optional association ends. What I did was simply remove the unique and not null constrains from DDL generated (without removing it it would be impossible to have a Person record that doesn't reference a Passport record):
from
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NOT NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
UNIQUE(PassUniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
to
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
but leave the uniqueness attribute in the mapping file:
<many-to-one
name="pass"
class="application.business.logic.Passport"
cascade="save-update,merge"
unique="true"
>
<column name="PassUniqueId"/>
</many-to-one>
The resulting solution worked fine and I was able to create instances of Person not linked to a Passport. However Hibernate didn't succed in keeping the association from degrading into a many-to-one. It enabled me to create two Persons linked with the same Passport:
PASSUNIQUEID | VIRSION | UNIQUEID | Name
================================================
0d8b3919fffff | 1 | 0d5fb1dcfff | John
0d8b3919fffff | 0 | 10fd07bdfff | Sam
A subsequent attempt at retrieving such Persons with Hibernate failed:
org.hibernate.HibernateException: More than one row with the given identifier was found: 0d8b3919ffffffd60151e135b6da0164, for class: application.business.logic.Passport.
Hibernate should be able to impose the single end property of such associations without relying on the underlying RDBMS engine and never allow them to degrade to many-to-ones.
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-2835) Setting org.hibernate.type logging to debug produces no logging
by Jeremy Grodberg (JIRA)
Setting org.hibernate.type logging to debug produces no logging
---------------------------------------------------------------
Key: HHH-2835
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2835
Project: Hibernate3
Issue Type: Bug
Components: core, documentation
Affects Versions: 3.2.5, 3.2.4
Environment: Hibernate 3.2.4.ga and Hibernate 3.2.5.ga with MySQL5Dialect (configured with Hibernate Annotations 3.3.0.ga and Spring 2.0.6)
Reporter: Jeremy Grodberg
Priority: Minor
According to the online documentation (labeled as version 3.2.2 at this moment), Table 3.9 "Hibernate Log Categories", as viewed here today:
http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat...
Setting the log4j category "org.hibernate.type" to debug should "Log all JDBC parameters". However, it produces no output at all.
When I go on to set "org.hibernate" to debug, I get output like this:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG: org.hibernate.SQL - select count(*) from album where genreID=?
DEBUG: org.hibernate.loader.Loader - bindNamedParameters() 126 -> genreId [1]
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG: org.hibernate.loader.Loader - result row:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close ResultSet (open ResultSets: 1, globally: 1)
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
Note that the JDBC parameters are logged under org.hibernate.loader but nothing appears under org.hibernate.type. FYI, genreId is, in this case, a Long.
Perhaps this is expected/desired when using annotations? If so, then please update the documentation. If not, please restore the logging.
--
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