[Hibernate-JIRA] Commented: (HHH-1088) IdentifierProjection does not work with composite keys
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
Gail Badner commented on HHH-1088:
----------------------------------
When EnhanceProjection is put in place, composite IDs will work for IdentifierProjection, components will work with PropertyProjection, and both will work with ProjectionList.
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-criteria
> Affects Versions: 3.1 rc2
> Reporter: Max Muermann
> Assignee: Gail Badner
> Fix For: 3.5.0.Next
>
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
[Hibernate-JIRA] Created: (HHH-3159) Oracle 11g - desupport of oracle.jdbc.driver
by D. S. (JIRA)
Oracle 11g - desupport of oracle.jdbc.driver
--------------------------------------------
Key: HHH-3159
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3159
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5GA, Oracle 11.1.0.6.0.
Reporter: D. S.
With Oracle 11g, the deprecated package oracle.jdbc.driver no longer exists and this causes issues with all OracleDialect classes making it impossible to use Hibernate.
This issue affects all of the following classes:
Oracle9iDialect.java
Oracle9Dialect.java
Oracle10gDialect.java
The line error in question is:
Class types = ReflectHelper.classForName("oracle.jdbc.driver.OracleTypes");
This simply needs to be changed to:
Class types = ReflectHelper.classForName("oracle.jdbc.OracleTypes");
>From the Oracle 11g readme.txt
"In Oracle JDBC release 9.0.1 customer use of the classes
in that package was deprecated. A new package, oracle.jdbc, was
introduced and customers were advised to begin using the
interfaces and classes defined in oracle.jdbc. In every release
since 9.0.1 we have encouraged customers to switch to oracle.jdbc
and stated that oracle.jdbc.driver would be desupported. The time
has come. Customer code that references oracle.jdbc.driver will
not compile and will not execute in this and future releases of
the Oracle JDBC drivers. Please use oracle.jdbc instead."
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
14 years, 3 months
[Hibernate-JIRA] Created: (HHH-3682) OracleDialect with oracle 11g
by akash (JIRA)
OracleDialect with oracle 11g
-----------------------------
Key: HHH-3682
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3682
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.2.5
Environment: Oracle 10.2, weblogic 10.3 , java 1.6 , spring 2.0
Reporter: akash
We are calling sql procedures using Hiberante and I have used OracleDialect9 as my hiberante dialect.
These configuration is working fine in weblogic 8.1 but it's failing in weblogic 10.3 with exception "Caused by: java.lang.IllegalAccessException: Class org.hibernate.dialect.Oracle9Dialect can not access a member of class oracle.jdbc.driver.OracleTypes with modifiers ""
" .
I went through the dialect code and found that here is one line "Class types = ReflectHelper.classForName("oracle.jdbc.driver.OracleTypes");" to load OracleTypes where in oracle 11g they have depricated oracle.jdbc.driver package. Now since weblogic 10.3 internally comes with oracle 11g thin driver, hibernate is not able to find OracleTypes class.
So what do u think what i should do to make this work ? Is there any dialect available which can support oracle 11g and solve this problem ? So should i created my own dialect and handle this issue ?
--
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
[Hibernate-JIRA] Commented: (HHH-1088) IdentifierProjection does not work with composite keys
by Paul Benedict (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
Paul Benedict commented on HHH-1088:
------------------------------------
Unless EnhancedProjection has uses beyond composite keys, should it just be called Composite[Key]Projection?
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-criteria
> Affects Versions: 3.1 rc2
> Reporter: Max Muermann
> Assignee: Gail Badner
> Fix For: 3.5.0.Next
>
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
[Hibernate-JIRA] Created: (HSEARCH-473) Fields for _hibernate_class and the document ID are hard-coded to be analyzed and have "norms" enabled
by Dobes Vandermeer (JIRA)
Fields for _hibernate_class and the document ID are hard-coded to be analyzed and have "norms" enabled
------------------------------------------------------------------------------------------------------
Key: HSEARCH-473
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-473
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.1.1.GA
Reporter: Dobes Vandermeer
A little-known problem with lucene is that it allocates one or more bytes of memory per document in the index when "norms" are enabled for one or more fields involved in a query. These norms are used for sorting/ranking but not necessarily for search.
Currently hibernate search uses special field fields for "id" and "_hibernate_class" with norms *enabled*, which means these norms arrays are created whenever hibernate search deletes something from the index as it uses those fields to find the related document. This results in unnecessary memory use (many megabytes for an index with millions of records in it).
Although this can be worked around by simply allocating a larger heap to the JVM it can become quite a significant issue if you plan to support hundreds of simultaneous users on a DB with millions of records; any user action that triggers an entity deletion may cause the norms array to be created, so you may have to allocate hundreds of megabytes of heap just to allow for the creation of these unnecessary norms arrays. This may still be mitigated by using asynchronous search index updates so that there's a fixed number of threads processing the deletions, I haven't confirmed whether that is the case or not.
The definition of these fields is hard-coded and they do not pay any attention to any @Field or @FieldBridge annotation on the id of the entity:
{code:java|title=org.hibernate.search.engine.DocumentBuilderIndexedEntity.getDocument(T, Serializable, Map<String, String>)}
Field classField =
new Field(
CLASS_FIELDNAME,
entityType.getName(),
Field.Store.YES,
Field.Index.NOT_ANALYZED,
Field.TermVector.NO
);
doc.add( classField );
// now add the entity id to the document
LuceneOptions luceneOptions = new LuceneOptionsImpl(
Field.Store.YES,
Field.Index.NOT_ANALYZED, Field.TermVector.NO, idBoost
);
idBridge.set( idKeywordName, id, doc, luceneOptions );
{code}
The fix is relatively straightforward, you simply have to use Field.Index.NO_NORMS_NOT_ANALYZED instead of Field.Index.NOT_ANALYZED for both these fields.
Related to http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-469
--
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
[Hibernate-JIRA] Created: (HHH-4112) HibernateProxy enhanced POJOs lose method annotations
by David Green (JIRA)
HibernateProxy enhanced POJOs lose method annotations
-----------------------------------------------------
Key: HHH-4112
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4112
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.0.ga
Reporter: David Green
Using FetchType.LAZY on an association can result in POJO entities being enhanced via JavassistProxyFactory or CGLIBProxyFactory. The resulting class overrides all declared accessors and mutators (get/set methods) in the original POJO. Those overridden methods lose any annotations that were specified on the original POJO.
The result is that unsuspecting code looking for annotations on POJO accessors won't find any annotations.
For example, if I have an @Entity POJO called Resident, the following JUnit test will fail for both CGLIBProxyFactory and JavassistProxyFactory:
{code:Java}
public void testCGLibProxy() throws HibernateException, SecurityException, NoSuchMethodException {
doTest(new CGLIBProxyFactory());
}
public void testJavassistProxy() throws HibernateException, SecurityException, NoSuchMethodException {
doTest(new JavassistProxyFactory());
}
private void doTest(ProxyFactory proxyFactory) throws NoSuchMethodException {
HashSet proxyInterfaces = new HashSet();
proxyInterfaces.add( HibernateProxy.class );
proxyFactory.postInstantiate("Resident", Resident.class, proxyInterfaces, Resident.class.getDeclaredMethod("getId"), Resident.class.getDeclaredMethod("setId",Long.class), null);
HibernateProxy hibernateProxy = proxyFactory.getProxy(resident.getId(), session);
assertTrue(hibernateProxy instanceof Resident);
System.out.println("Hibernate proxy name: "+hibernateProxy.getClass().getName());
assertNotNull(Resident.class.getDeclaredMethod("getMaritalStatus").getAnnotation(Required.class));
assertNotNull(hibernateProxy.getClass().getDeclaredMethod("getMaritalStatus").getAnnotation(Required.class));
}
{code}
--
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
[Hibernate-JIRA] Updated: (HHH-1088) IdentifierProjection does not work with composite keys
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
Gail Badner updated HHH-1088:
-----------------------------
Fix Version/s: (was: 3.3.x)
Full support for composite ID and component projections will require additions to the API.
I'm creating EnhancedProjection, which extends Projection and adds the required methods.
SimpleProjection, PropertyProjection, ProjectionList, and some other classes that extend Projection will be changed to extend EnhancedProjection.
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-criteria
> Affects Versions: 3.1 rc2
> Reporter: Max Muermann
> Assignee: Gail Badner
> Fix For: 3.5.0.Next
>
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
[Hibernate-JIRA] Created: (HHH-2575) Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used
by Mike Hoeffner (JIRA)
Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used
------------------------------------------------------------------------------------------------------------
Key: HHH-2575
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2575
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.2.2
Environment: Hibernate 3.2.2 + MySQL 5.0.22 + MySQL Connector/J 5.0.5. Reproduced with HSQLDB 1.8.0.7.
Reporter: Mike Hoeffner
Priority: Minor
Attachments: ResultsNotEffectedByAliasesTest.java
I had a SQL (not HQL) query that basically looked like this:
select a.name, a.seq, b.name, b.seq from foo a, foo b;
and I noticed that the results obtained through list() -> (Object[]) get(i) -> row[0], row[1], row[2], row[3]
did not correspond to what I saw when manually running the query without Hibernate involved. row[2] always had the same values as row[0] and row[3] always had the same values as row[1].
When I tried adding aliases so that it became:
select a.name as a_name, a.seq as a_seq, b.name as b_name, b.seq as b_seq from foo a, foo b;
then the results matched what I expected. So having aliases in the SQL modified the results that were returned even though I was looking up the value from each column by its index / position instead of by its name / alias.
Attached is a test case that will reproduce 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
14 years, 3 months