April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4723) Column in SQL query is returned as java.lang.Character

by Nick de Graeve (JIRA)

Column in SQL query is returned as java.lang.Character ------------------------------------------------------ Key: HHH-4723 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4723 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.1 Reporter: Nick de Graeve When I run this code sample: {{List data = session.createSQLQuery("select e.country_iso_code from agent.tbd3_Entry e where e.country_iso_code = 'BE'").list();}} {{Object row = data.get(0);}} {{System.out.print(row + ": " + row.getClass());}} I get this result: {{B: class java.lang.Character}} I expect to get a {{java.lang.String}} containing "BE", not just the 1st Character. The column country_is_code of table tbd3_entry is defined in Oracle as {{COUNTRY_ISO_CODE CHAR(2 BYTE)}} When I add a scalar with correct type I do get what I need: {{List data = session.createSQLQuery("select e.country_iso_code countryIsoCode from agent.tbd3_Entry e where e.country_iso_code = 'BE'").addScalar("countryIsoCode", Hibernate.STRING).list();}} {{Object row = data.get(0);}} {{System.out.print(row + ": " + row.getClass());}} results in {{BE: class java.lang.String}} -- 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, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3313) Criteria + Property Projection + LockMode causes a NPE

by Christian Nelson (JIRA)

Criteria + Property Projection + LockMode causes a NPE ------------------------------------------------------ Key: HHH-3313 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3313 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.6 Environment: Hibernate 3.2.6.ga, PostgreSQL 8.1 Reporter: Christian Nelson Attachments: hibernate-criteria-projection-lockmode-project.zip In converting a working HQL query to the Criteria API, we stumbled upon what looks very much like a bug. When combining a criteria with a projection and setting the lockmode (to read or upgrade), hibernate throws a NPE down in CriteriaLoader.applyLocks(). Here's a simplified snippet of the criteria that results in the exception: Criteria criteria = session.createCriteria(Article.class).add(Restrictions.ilike("title", "%frozen%")); criteria.createCriteria("moderation", "m").add(Restrictions.eq("approved", true)); criteria.setProjection(Projections.property("moderation")); criteria.setLockMode("m", LockMode.UPGRADE); assertions(criteria.list()); [The test case includes other attempts at building a similar criteria using different approaches.] And here's the stack trace: java.lang.NullPointerException at org.hibernate.loader.criteria.CriteriaLoader.applyLocks(CriteriaLoader.java:131) at org.hibernate.loader.Loader.preprocessSQL(Loader.java:201) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538) at org.hibernate.loader.Loader.doQuery(Loader.java:673) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2213) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283) There's already some talk on the web about this problem: * http://forum.hibernate.org/viewtopic.php?t=955525 * http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78... I've created a simplified test case which includes the HQL version of the query (works), the Criteria version without lockmode (works), and then 3 failing tests illustrating the problem. The attached zip contains the test case and supporting files. The source code for the test case is also available via anonymous svn access (http://svn.carbonfive.com/public/christian/hibernate-criteria-projection-...). The test will run out of the box using maven against an h2database in-memory database with no setup. This combination of features doesn't seem that obscure so I'd expect it to work, or at the very least, report that it is not supported in a more graceful manner. -- 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, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2304) Wrong type detection for sql type char(x) columns

by Markus Heiden (JIRA)

Wrong type detection for sql type char(x) columns ------------------------------------------------- Key: HHH-2304 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2304 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0, Oracle 9.2, Oracle JDBC driver 10.2 Reporter: Markus Heiden Attachments: hibernate.zip When executing a sql query which returns columns of sql type char(x), a java.lang.Character is returned. This leads to returning just the first character of the value. In my eyes a String should be returned when the char(x) type has a width > 1. I wasn't able to determine whether this is a jdbc driver issue or a hibernate issue. When using sql type char(x) for columns of entities no such problems occur. Test case is attached. -- 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, 9 months

8
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-395) Master/Slave configuration as outlined in Hibernate Search in Action does not work when shared location is on NFS

by Sam Doyle (JIRA)

Master/Slave configuration as outlined in Hibernate Search in Action does not work when shared location is on NFS ----------------------------------------------------------------------------------------------------------------- Key: HSEARCH-395 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-395 Project: Hibernate Search Issue Type: Bug Components: directory provider Affects Versions: 3.1.1.GA Reporter: Sam Doyle Priority: Critical https://forum.hibernate.org/viewtopic.php?f=9&t=998613&p=2416681#p2416681 There are many .nfs files being generated in slave locations and appear to be still held open by some part of the application since they fail to be cleaned up. 2009-08-21 10:51:08,696 ERROR [org.hibernate.search.util.FileHelper] Could not delete /location/to/slave/index/2/.nfs000000000085a3ce000016 7e -- 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, 9 months

4
8
0 / 0

[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, 9 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, 9 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, 9 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, 9 months

4
3
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, 9 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-4854) Make constraint violation name extraction language neutral

by Jonas Olsson (JIRA)

Make constraint violation name extraction language neutral ---------------------------------------------------------- Key: HHH-4854 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4854 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Environment: Oracle 8 or later Reporter: Jonas Olsson The ViolatedConstraintNameExtracter of Oracle8iDialect uses the following pattern for extracting the contraint violated: return extractUsingTemplate( "constraint (", ") violated", sqle.getMessage() ); and is highly error message language dependent. Changing to: return extractUsingTemplate( "(", ")", sqle.getMessage() ); would eliminate this while still getting the constraint name. -- 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, 9 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010