October 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-159) Sort + Pagination returns wrong results.

by Jason Eacott (JIRA)

Sort + Pagination returns wrong results. ---------------------------------------- Key: HSEARCH-159 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-159 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.0.1.GA Environment: hib 3.2.5ga Reporter: Jason Eacott Perhaps I am doing something wrong? Using the code below if I call getSearchResults("test",0,10); //returns incorrect data I get a different item at the head of the list than if I call getSearchResults("test",0,100);// (this one has correct data, total results for this search is 196 in my ndx & db) if I dont try to paginate the results then the sort items are in order and are correct. and if I paginate with just 1 result getSearchResults("test",0,1); and change the sort order I get the same result for each attempt: ie: Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) ); and Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, false ) ); return the same entry - which is NOT the correct result either. This behavious seems to indicate that the data is being sorted after the limit is set and whats worse, if there are 50,000,000 results, even though I only want 10 and hibernate has already correctly hydrated those 10 (albeit the wrong 10) hibernatesearch then loops over all 50,000,000 hits and creates a new (empty) hibernate proxy object for each & discard all but 10! ... @Field(name="date_time", index=Index.UN_TOKENIZED, store=Store.NO) @DateBridge(resolution=Resolution.MINUTE) private Date publishDate; ... public List getSearchResults(Query query,int firstResult,int maxResults) { List result=null; Session sess=null; Transaction tx = null; try { sess=getSessionFactory().openSession(); FullTextSession fullTextSession = Search.createFullTextSession(sess); tx = fullTextSession.beginTransaction(); tx.begin(); org.hibernate.search.FullTextQuery hibQuery= fullTextSession.createFullTextQuery( query, FeedItem.class ); Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) ); hibQuery.setSort(datesort); Criteria dbCr=fullTextSession.createCriteria(FeedItem.class); hibQuery.setCriteriaQuery(dbCr); dbCr.setFirstResult(firstResult); dbCr.setMaxResults(maxResults); } long resultSize=hibQuery.getResultSize(); if (resultSize>0){ result = hibQuery.list() } tx.commit(); } finally { releaseSession(sess); tx=null; } log.debug("<getSearchResults"); return result; } -- 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

12 years, 7 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3429) SQLQuery, advice user to always use addScalar if CHAR column are involved.

by Anthony Patricio (JIRA)

SQLQuery, advice user to always use addScalar if CHAR column are involved. -------------------------------------------------------------------------- Key: HHH-3429 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3429 Project: Hibernate3 Issue Type: Improvement Components: documentation Reporter: Anthony Patricio Priority: Minor see HHH-2220 If CHAR(2+) is involved in a SQLQuery and if addScalar isn't used, then the returned value is truncated which is very bad. There is no easy fix for this so a little advice in the documentation would be helpful. -- 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

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2220) session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String

by Regis Pires Magalhaes (JIRA)

session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String ------------------------------------------------------------------------------------------------ Key: HHH-2220 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2220 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.ga Reporter: Regis Pires Magalhaes createSQLQuery() method translates database type CHAR(n) to Java type char instead of String when using setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP). That happens when I do not use addScalar(). And that is the only problem that I have found when not filling return types in advance. A workaround I have made is to concatenate the projected field with an empty string (''). See example below: ... query.setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP); String sqlQuery = "select s.name state from state s where s.name='PI' "; query = session.createSQLQuery(sqlQuery); ... result: [{STATE=P}] name field is CHAR(2) in database definition (PostgreSQL, HSQLDB and Oracle were tested). Note that it works when I concatenate the field used in projection with an empty string: ... String sqlQuery = "select s.name || '' state from state s where s.name='PI' "; ... result: [{STATE=PI}] -- 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

12 years, 7 months

8
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2429) SQL Character Types Incorrectly mapped to Java objects

by Tyler Van Gorder (JIRA)

SQL Character Types Incorrectly mapped to Java objects ------------------------------------------------------ Key: HHH-2429 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2429 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Oracle10g Reporter: Tyler Van Gorder We have a work flow that allows the user to enter an arbitrary SQL statement to be executed by our application. We pass those queries through session.createSQLQuery(). We ran into a problem with String literals, which are reported by Oracle (ResultSetMetaData) to be CHAR. Reading the JDBC API, CHAR is a fixed length string. Hibernate is incorrectly mapping this to a Character field. We ended up overriding the Oracle dialect with our own as follows: In our constructor, for a dialect that extends Oracle9iDialect: super() registerColumnType(Types.CHAR, "char($l)" ); registerHibernateType( Types.CHAR, Hibernate.STRING.getName() ); The HibernateType is the crucial one and we are overriding the behavior in the base "Dialect" class, so this appears that it would be a problem for all database variants that don't explicitly change this. Thanks. -- 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

12 years, 7 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-944) default two way String bridge for type java.util.UUID

by Gregory (JIRA)

default two way String bridge for type java.util.UUID ------------------------------------------------------ Key: HSEARCH-944 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-944 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 4.0.0.Beta2 Environment: Hibernate search 4.0.0.Beta2 independent of any database Reporter: Gregory Priority: Minor Added a Two way String bridge for java.util.UUID. This will allow users of hibernate search to set the @documentID tag on id's using UUID with out their own field bridge. I have completed the work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HV-441) Refactor BeanMetaDataImpl

by Hardy Ferentschik (JIRA)

Refactor BeanMetaDataImpl ------------------------- Key: HV-441 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-441 Project: Hibernate Validator Issue Type: Task Components: engine Reporter: Hardy Ferentschik Fix For: 4.x Due to the introduction of method level validation the {{BeanMetaDataImpl}} abstraction started leaking. For example parts of the configuration data is now held at multiple places. We have to start addressing this and pull things together again. I started a discussion around this with Gunnar. My original question was: {quote} Could you have a look at my branch https://github.com/hferentschik/hibernate-validator/commits/HV-433. The tests for this issue are passing (CascadingWithConstraintMappingTest), in fact the whole test suite is passing. The problem I encountered was around MethodMetaData and its cascading flag. In the case of the test case it was not properly set. The code was just looking for the @Valid annotation, but also has to check whether the method is explicitly (xml or programmatic api) configured for cascading. If you have a look at the branch you see how I changed that. The question which came up in my mind is, whether there is not duplication between MethodMetaData and BeanMetaData (at least regarding the cascading). {quote} Gunnar's response: {quote} Yes, that's certainly right. Actually I'm not quite happy with BeanMetaDataImpl altogether atm. It is pretty complex code, is quite huge and I think we should tidy up/restructure it for 4.3. When implementing method validation I found that the meta model was not expressive enough for the new method stuff, which was why I came up with more powerful model classes accompanying BeanMetaData such as MethodMetaData and ParameterMetaData. The idea was that the engine (ValidatorImpl) could simply ask a MethodMetaData whether it requires cascaded validation or not for instance. At the same time I tried to to modify existing functionality in BeanMetaDataImpl not more than necessary. So currently the situation is, that method validation is based on MethodMetaData#isCascading(), while standard bean/property validation relies on BeanMetaDataImpl#cascadingMembers. In BMDI's constructor both structures are maintained. Actually I'm proceeding on that path for HV-371. There I introduced AggregatedMethodMetaData which represents a given method *and* all the methods up in the hierarchy which it overrides/implements (basically this replaces the Map<Class<?>, Map<Method, MethodMetaData>> methodMetaConstraints with Map<Method, AggregatedMethodMetaData> methodMetaData. This should make things much easier in ValidatorImpl, which now can deal with one AggregatedMethodMetaData object instead of iterating over the complete inheritance hierarchy (So for instance AMMD#isCascading() answers whether a cascaded validation is required for the given method no matter where in the hierarchy it was marked with @Valid). So I definitely think we should get these things more aligned again but I've got the feeling we can live with the situation temporarily. WDYT? {quote} -- 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

12 years, 7 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-945) Arquillian integration test fails due to bug in Shrinkwrap

by Hardy Ferentschik (JIRA)

Arquillian integration test fails due to bug in Shrinkwrap ---------------------------------------------------------- Key: HSEARCH-945 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-945 Project: Hibernate Search Issue Type: Bug Components: tests Affects Versions: 4.0.0.Beta2 Reporter: Hardy Ferentschik Fix For: 4.0.0.CR1 The current setup of the Arquillian integration test fails due to SHRINKWRAP-294 Dependencies need to be updated and we should use the Arquillian bom to manage versions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5944) Refresh of an entity should clear its entries in the action queue

by Jonas Olsson (JIRA)

Refresh of an entity should clear its entries in the action queue ----------------------------------------------------------------- Key: HHH-5944 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5944 Project: Hibernate Core Issue Type: New Feature Components: core Affects Versions: 3.3.2 Environment: JBoss 4.2.3 Spring 2.5.5 Reporter: Jonas Olsson We're using optimistic locking for some statistics entities and are doing re-tries on StaleObjectStateException by refreshing the entity and re-applying our update. However, this fails in the same way every time as the failed update lingers in the action queue and is flushed before the changed update. Shouldn't/Couldn't refresh clear the action queue from actions of the given entity? As it is now it's quite nasty as you think you know what the instance looks like, but there is a hidden update just waiting for a flush. Our work-around is to cast Session to EventSource and clear the action queue ourselves (we pre-flush the session before the optimistic locking update to ensure the failed update is the only one queued), but that feels a bit like a hack. -- 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

12 years, 7 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HCANN-10) JPA OneToOne(optional=true) not supported, supported alternative NotFound() is hibernate-proprietary!

by Bruno Melloni (JIRA)

JPA OneToOne(optional=true) not supported, supported alternative NotFound() is hibernate-proprietary! ----------------------------------------------------------------------------------------------------- Key: HCANN-10 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-10 Project: Hibernate Commons Annotations Issue Type: Bug Environment: Hibernate 3.3.1, annotations 3.4.0, MsSQL DB. Reporter: Bruno Melloni Rejected issue ANN-725 covers this partially. I might have misunderstood, but it seems the reason for rejecting is that @NotFound provides the same capability. All information I could find for JPA and other ORM tools indicates that this capability is supplied by @OneToOne(optional=true). Hibernate seems to be the lone ORM tool that requires the use of a proprietary annotation: @NotFound. @NotFound works, but the problem is that it makes the application no longer be pure-JPA. Not supporting pure-JPA outer joins would seem to be a major 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

12 years, 7 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-6717) oracle does not have a boolean type

by Strong Liu (JIRA)

oracle does not have a boolean type ----------------------------------- Key: HHH-6717 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6717 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.0.0.next now Dialect has mapped Types.BOOLEAN to 'boolean' by default, then we need change this in Oracle dialect to let it map to _char(1)_ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2011