May 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3318) Allow omitting varchar limit by default in PostgreSQL

by Luke Maurer (JIRA)

Allow omitting varchar limit by default in PostgreSQL ----------------------------------------------------- Key: HHH-3318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3318 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Hibernate 3.2.6, PostgreSQL 8.3.1 Reporter: Luke Maurer Priority: Minor Essentially, what I'd like is for a String without a given maximum length be mapped as a varchar or text rather than a varchar(255) as is now the case. The maximum doesn't do anything to improve performance or storage efficiency in PostgreSQL, so varchar(255) merely imposes an arbitrary constraint. It would be more idiomatic to use varchar where no limit is given, leaving varchar(n) for cases where the length is limited as a business rule rather than an implementation detail. (Naturally, one can always use @Lob where it's actually *important* that the column be a varchar or text. So this is definitely 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

13 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-710) Add option to index fields using ANALYZED_NO_NORMS

by Sanne Grinovero (JIRA)

Add option to index fields using ANALYZED_NO_NORMS -------------------------------------------------- Key: HSEARCH-710 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-710 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.4.0.Beta1 It seems it's currently not possible to use the indexing option org.apache.lucene.document.Field.Index.ANALYZED_NO_NORMS (workaround: use a custom fieldbridge) -- 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

13 years, 4 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-711) Review of org.hibernate.search.annotations.Index API (token names, parameter composition)

by Sanne Grinovero (JIRA)

Review of org.hibernate.search.annotations.Index API (token names, parameter composition) ----------------------------------------------------------------------------------------- Key: HSEARCH-711 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711 Project: Hibernate Search Issue Type: Deprecation Reporter: Sanne Grinovero Fix For: 4.0 We're having Enum values labeled NO,TOKENIZED,UN_TOKENIZED,NO_NORMS,.. while Lucene changed these names to more suited "analyzed", "not_analyzed", etc. Also I think it would be great to use an array of parameters instead of an enum listing all options, or maybe split the option in two: @Field({ANALYZE,NO_NORMS}) or @Field(analyze=YES,norms=No) We should at least deprecate current names and use the more appropriate terms. -- 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

13 years, 4 months

2
14
0 / 0

[Hibernate-JIRA] Created: (HHH-5645) Criteria.createAlias with specified criterion results in wrong parameters passed into SQL statement

by Fekete Kamosh (JIRA)

Criteria.createAlias with specified criterion results in wrong parameters passed into SQL statement --------------------------------------------------------------------------------------------------- Key: HHH-5645 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5645 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.6 Environment: Windows XP SP2, Hibernate 3.5.6, JRE 1.6.0_14, PostgreSQL (tested also with Sybase ASE) Reporter: Fekete Kamosh Attachments: aliases_test.zip Suppose to have tables A, B, C. Relationships: A(one)=>B(many); B(one)=>C(many) Table A is used as main entity. For tables B and C lets *establish aliases* using method _public Criteria createAlias(String associationPath, String alias, int joinType, *Criterion withClause*) throws HibernateException;_ Each created alias has addition Criterion to force Hibernate generate clause _"on column = column and (other_criterion_condition)"._ If aliases are created in *order B, C* everything is OK: Resulting SQL: _SELECT this_.table_a_character AS y0_ FROM table_a this_ LEFT OUTER JOIN table_b tablebalia1_ ON this_.table_a_id = tablebalia1_.table_a_id AND ( tablebalia1_.table_b_date = ? ) LEFT OUTER JOIN table_c tablecalia2_ ON tablebalia1_.table_b_id = tablecalia2_.table_b_id AND ( tablecalia2_.table_c_boolean = ? ) WHERE this_.table_a_character = ?_ Passed parameters: *[Sun Oct 10 22:09:31 CEST 2010, false, c]* But if aliases are created in *order C, B error occurs* as resulting SQL remains the same as already shown, but Passed parameters are: *[false, Sun Oct 10 22:12:13 CEST 2010, c]* which causes SQL exception, because there are passed *parameters in wrong order to SQL statement*: 43843 [main] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 42883 43843 [main] ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: operator does not exist: date = boolean *Test example* (database tables, entities, hibernate.cfg and test file) *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

13 years, 4 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-620) Archetype does not deploy on JBoss Nexus repository due to missing pom fields

by Hardy Ferentschik (JIRA)

Archetype does not deploy on JBoss Nexus repository due to missing pom fields ----------------------------------------------------------------------------- Key: HSEARCH-620 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-620 Project: Hibernate Search Issue Type: Bug Components: build Affects Versions: 3.3.0.Beta3 Reporter: Hardy Ferentschik Fix For: 3.3.0.CR1 The quickstart archetype does not deploy on the Nexus server, because the test pom is missing several project information fields. For the purpose of the archetype this is not a problem, but it seems that Nexus is configured to verify certain pom fields. Using the current configuration I was not able to close the staging repository (see screenshot). As a solution we can add dummy fields for the required nodes. We should also talk to Paul - do this rules always makes sense? -- 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

13 years, 4 months

4
22
0 / 0

[Hibernate-JIRA] Created: (HHH-6123) Patch to support Oracle Hints in Hibernate queries

by Tad Smith (JIRA)

Patch to support Oracle Hints in Hibernate queries -------------------------------------------------- Key: HHH-6123 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6123 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.6.2 Reporter: Tad Smith Attachments: hibernate-oracle-hints-patch.zip Supporting Oracle hints in Hibernate is a feature often requested by Hibernate users, though I'll admit should be used very rarely in practice. Actually, I had a manager that demanded it if we were to continue using Hibernate (He was new to the project with a C++/DBA background.), so I modified Hibernate to support it. I did this originally 2 years ago against Hibernate version 3.3.1. I've just updated it to support Hibernate version 3.6.2. It would be great if this could be included in the Hibernate baseline. It's a relatively minor change and the design follows existing Hibernate patterns. Thanks, Tad General Design: ======================== I modeled the implementation after the org.hibernate.dialect.Dialect.getLimitString() method. I added a new method to the org.hibernate.dialect.Dialect class called getQueryHintString(). I also modified the org.hibernate.Criteria and org.hibernate.Query interfaces to add a new method called setQueryHint(). This means you can create a Query from an HQL string and then apply the Oracle hint. Other Dialect class implementation would easy override the getQueryHintString() method to support hints for other databases. What's included in the patch: =============================== I've included the 9 classes that were modified to support Oracle hints. I've also included a Maven POM file that should be able to generate the patch jar automatically and upload it to your Maven Repository. Just change the artifactId from "hibernate-core" to "hibernate-core--OracleHintsPatch". (I'm relatively new to Maven and this has not received much testing, so feel free to improve upon it.) -- 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

13 years, 4 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3244) Implement support NVARCHAR type

by Sergey Derugo (JIRA)

Implement support NVARCHAR type -------------------------------- Key: HHH-3244 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3244 Project: Hibernate3 Issue Type: New Feature Components: core Environment: al Reporter: Sergey Derugo JDBC 4.0 allows supports NVARCHAR type, but Hibernate doesn't handle it. Please implement support for NVarchar -- 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

13 years, 4 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2955) Unnecessary version updates in two cases.

by Sławomir Wojtasiak (JIRA)

Unnecessary version updates in two cases. ----------------------------------------- Key: HHH-2955 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2955 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: JDK 5.0 Reporter: Sławomir Wojtasiak Attachments: HibernateTest.zip I found two situations where hibernate generates unnecessary version updates. Let's illustrate it with a simple example: Session session = SessionFactory.getSession(); Transaction transaction = session.getTransaction(); transaction.begin(); Article a = new Article(); a.setName( "atricle" ); ********************************************* *** Quantity is the owner of the relation *** ********************************************* Quantity q = new Quantity(); q.setName( "quantity" ); q.setArticle( a ); a.getQuantities().add( q ); session.persist( a ); session.flush(); ***** Hibernate generates following SQLs ***** Hibernate: select nextval ('hibernate_sequence') Hibernate: select nextval ('hibernate_sequence') Hibernate: insert into Article (name, version, id) values (?, ?, ?) Hibernate: insert into Quantity (article_id, name, version, id) values (?, ?, ?, ?) ********************************************** a.getQuantities().clear(); session.flush(); *** Hibernate generates following SQLs *** Hibernate: update Article set name=?, version=? where id=? and version=? This update of version field is performed because collection of quantities is marked as dirty, but Article entity is not relation owner so nothing change in database after this clear. Should it works like this? It looks like a bug because database remain unchanged so version changing is unnecessary in my opinion. ****************************************** session.clear(); **** SECOND PROBLEM *** Now I generate true copy of persisted objects. Notice that I use HashSet instead of PersistSet which was set during persist operation. This operation is similar to merging objects prepared by SOAP, during communication with remote client for example. *********************** Article a1 = new Article(); a1.setId( a.getId() ); a1.setName( a.getName() ); a1.setVersion( a.getVersion() ); Quantity q1 = new Quantity(); q1.setArticle( a1 ); q1.setName( q.getName() ); q1.setVersion( q.getVersion() ); q1.setId( q.getId() ); a1.getQuantities().add( q1 ); a1 = (Article)session.merge( a1 ); session.flush(); ***** This operation generates following SQLs ***** Hibernate: select article0_.id as id0_1_, article0_.name as name0_1_, article0_.version as version0_1_, quantities1_.article_id as article4_3_, quantities1_.id as id3_, quantities1_.id as id1_0_, quantities1_.article_id as article4_1_0_, quantities1_.name as name1_0_, quantities1_.version as version1_0_ from Article article0_ left outer join Quantity quantities1_ on article0_.id=quantities1_.article_id where article0_.id=? Hibernate: update Article set name=?, version=? where id=? and version=? It looks like problem is located in replaceElements() method of CollectgionType class (or somewhere near it). Maybe I'm wrong but this collection was checked for changes during merge operation (See this select above.) so why it remains dirty if it contains the same data as database?. I checked this issue on other JPA implementations (OpenJPA for example) and version is not incremented after similar merge operation. ***************************************************** transaction.rollback(); -- 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

13 years, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (EJB-318) PostUpdate callback not called after update on a collection / association (@OneToMany for example)

by Aghnar von Salza (JIRA)

PostUpdate callback not called after update on a collection / association (@OneToMany for example) -------------------------------------------------------------------------------------------------- Key: EJB-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-318 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Environment: Hibernate core3.2.5, entityManager 3.3.1, annotation 3.3.0, oracle 9i Reporter: Aghnar von Salza Environment is Weblogic 10 (J2EE 5), with Hibernate used as JPA provider There is no PostUpdate callback on an entity when one of its collections of other Entities (for example annoted with @OneToMany) is updated (i mean when one entity element is added or removed). JPA specification says that a postUpate must be called after the update of at least one data of an entity. I think we have to consider that a collection of other entities can be considered as data. -- 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

13 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5580) tracking entity names in a revision

by Vardan Akopian (JIRA)

tracking entity names in a revision ----------------------------------- Key: HHH-5580 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5580 Project: Hibernate Core Issue Type: New Feature Components: envers Affects Versions: 3.5.5 Environment: hibernate 3.5.5 Reporter: Vardan Akopian Attachments: envers-entity-names.patch Currently Envers provides no way of finding which entities have been affected in a given revision. I.e. given a revision number it's impossible to find all the versions of all the entities for that revision. For example, all the search methods in the AuditQuery API take the entity class as a parameter. In our application we need to be able to retrieve all the changes for a given revision number without prior knowledge of which entities have been modified. Similar questions and requests have been posted in the envers forums before. The attached patch has a simple implementation for this feature. It adds 2 simple methods to the RevisionListener interface, that are called from AuditProcess and allow the Revision Entity to keep track of the entity names that are changed. The test cases show the simple usage for this. -- 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

13 years, 4 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2011