August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-881) @Fields annotation calling getter multiple times

by adam (JIRA)

@Fields annotation calling getter multiple times ------------------------------------------------- Key: HSEARCH-881 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-881 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.4.1.Final Environment: hibernate 3.6.6; postgres Reporter: adam Priority: Minor placing an @Fields annotation on a method appears to cause the method's getter to be called once for each @Field annotation inside the list. Depending on what's internal to the method, indexing speed may be optimized by setting the contents to a variable and thus only calling the method once. /* class snippit */ @Fields({ @Field(name = "allPhrase", analyzer = @Analyzer(impl = TdarStandardAnalyzer.class)), @Field(name = "all", analyzer = @Analyzer(impl = LowercaseWhiteSpaceStandardAnalyzer.class)) }) public String getKeywords() { logger.info("get keyword contents: {}",getId()); /* debug on save */ INFO 2011-08-29 10:37:30,828 12676 (Resource.java:982) org.tdar.core.bean.resource.Resource - get keyword contents: 4798 INFO 2011-08-29 10:37:30,828 12676 (Resource.java:982) org.tdar.core.bean.resource.Resource - get keyword contents: 4798 ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
6
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

14 years, 9 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

14 years, 9 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

14 years, 9 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-876) Extracted archetype does not compile

by Hardy Ferentschik (JIRA)

Extracted archetype does not compile ------------------------------------ Key: HSEARCH-876 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-876 Project: Hibernate Search Issue Type: Bug Components: build Affects Versions: 3.4.1.Final Reporter: Hardy Ferentschik When getting the latest archetype: {noformat} mvn archetype:generate -DarchetypeGroupId=org.hibernate -DarchetypeArtifactId=hibernate-search-quickstart -DarchetypeVersion=3.4.1.Final -DarchetypeRepository=http://repository.jboss.org/nexus/content/groups/public-jboss/ {noformat} and executing _mvn clean install_ after specifying the required information (using 1.0-SNAPSHOT as version), the following error occurs: {noformat} [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Hibernate Search Quickstart 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [WARNING] The POM for org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT is missing, no dependency information available [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.916s [INFO] Finished at: Thu Aug 25 17:03:41 CEST 2011 [INFO] Final Memory: 3M/81M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project bar: Could not resolve dependencies for project foo:bar:jar:1.0-SNAPSHOT: Failure to find org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT in http://localhost:8082/nexus/content/groups/jboss-dev-group/ was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExce... {noformat} I am not quite sure why _hibernate-search-analyzers_ in version _1.0-SNAPSHOT_ et requested. This feels like a maven bug. A fix is to explicitly add {code} <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-analyzers</artifactId> <version>${project.parent.version}</version> </dependency> {code} to the archetype pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
5
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

14 years, 9 months

4
22
0 / 0

[Hibernate-JIRA] Created: (HHH-6581) JPA 2.0 Spec. Violation with Access and MappedSuperclass

by Laird Nelson (JIRA)

JPA 2.0 Spec. Violation with Access and MappedSuperclass -------------------------------------------------------- Key: HHH-6581 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6581 Project: Hibernate Core Issue Type: Bug Components: annotations, core Affects Versions: 3.6.6 Reporter: Laird Nelson Once I create this issue and get the bug number I will be creating a test case. The bug is fully described in the Hibernate user forums: https://forum.hibernate.org/viewtopic.php?f=1&t=1012254 Suppose I have a {{@MappedSuperclass}} like this: {code:title=A.java} @Access(AccessType.FIELD) @MappedSuperclass public class A { private long id; @Column(name = "some_other_field") private String someOtherField; @Access(AccessType.PROPERTY) @Column(name = "id") @GeneratedValue @Id public long getId() { return this.id; } protected void setId(final long id) { this.id = id; } } {code} Then suppose I extend it with a (minimally-annotated) entity: {code:title=B.java} @Entity @Table(name = "b") public class B extends A { @Column(name = "long_description") private String longDescription; // various other persistent fields here public String getLongDescription() { return this.longDescription; } public void setLongDescription(final String description) { this.longDescription = description; } } {code} Hibernate 3.6.6.Final logs exceptions indicating that it cannot find the {{LONGDESCRIPTION}} column for this entity. This implies that somehow {{AccessType.PROPERTY}} has been used on the longDescription attribute, where {{AccessType.FIELD}} should have been used instead. This is a violation of the spec. It's almost like the mere fact that {{AccessType.PROPERTY}} was used in the {{@MappedSuperclass}} at all caused it to be "latched" as the default for the rest of the entity hierarchy, which is clearly not what should happen. Section 2.3.2 in the JPA 2.0 specification reads as follows: bq. An access type for an individual entity class, mapped superclass, or embeddable class can be specified for that class independent of the default for the entity hierarchy by means of the Access annotation applied to the class. This explicit access type specification does not affect the access type of other entity classes or mapped superclasses in the entity hierarchy. Then it also says, later: bq. Persistent state inherited from superclasses is accessed in accordance with the access types of those superclasses. My interpretation of all this is that I shouldn't have to put the {{@Access}} annotation on the {{@Entity}} in my example above. {{B.java}} should inherit the fact that the "{{id}}" property has {{AccessType.PROPERTY}}, and, by virtue of the default algorithm specified in section 3.2.1, should apply {{AccessType.FIELD}} to all other elements of its persistent state. Guy Pelletier from EclipseLink, upon having this all explained to him, says: bq. The behavior you describe is indeed intentionally implemented that way [i.e. no extra @Access annotation on B.java required] in EclipseLink as this is also our interpretation of the spec as well (and we confirmed with direct discussions with members of the spec committee beforehand). I'll put a test case together shortly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-890) Enable projection on unknown fields

by Sanne Grinovero (JIRA)

Enable projection on unknown fields ----------------------------------- Key: HSEARCH-890 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-890 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Alpha2 It seems that if the field is not known by the query engine, attempting to load strings by projection is not supported. We should make it possible to retrieve any stored field. https://forum.hibernate.org/viewtopic.php?f=9&t=1012344 and maybe https://forum.hibernate.org/viewtopic.php?f=9&t=1012420 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
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

14 years, 9 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6508) Integrator should be able to modify the ServiceRegistry

by Karel Maesen (JIRA)

Integrator should be able to modify the ServiceRegistry ------------------------------------------------------- Key: HHH-6508 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6508 Project: Hibernate Core Issue Type: Task Components: core Reporter: Karel Maesen Modules may need to override the ServiceRegistry. E.g. Spatial module may want to replace the registered DialectResolver with a resolver that returns spatially-enabled dialects (when available). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2011