August 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2059) Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does.

by Greg Luck (JIRA)

Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. ----------------------------------------------------------------------------------------- Key: HHH-2059 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2059 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Reporter: Greg Luck Priority: Minor Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. The only reason I am asking for this is that people are confused about it and are asking me questions over at the ehcache project. e.g. see the following email to the list. From: p.perrucci(a)gmail.com Subject: [ehcache-list] Using ehcache as a clustered cache in hibernate3 Date: 6 September 2006 6:29:21 PM GMT+10:00 To: ehcache-list(a)lists.sourceforge.net Hi all, current version of ehcache implements distributed caching but hibernate3 docs says that ehcache is not cluster safe. Anyone know the reason why it's not possible to use ehcache in such a scenario? Thanks Paolo ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_... ehcache-list mailing list ehcache-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ehcache-list -- 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, 2 months

6
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3112) Upgrade EhCache dependancy to 1.2.4+

by Stevo Slavic (JIRA)

Upgrade EhCache dependancy to 1.2.4+ ------------------------------------ Key: HHH-3112 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3112 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.2.5 Reporter: Stevo Slavic Priority: Trivial Hibernate is widely used in conjunction with Spring framework. Spring framework as of version 2.0 expects EhCache to be 1.2.4+. When using both EhCache 1.2.4+ and Hibernate 3.2.5.ga as dependency in same maven project but in different sub-projects, older EhCache 1.2.3 (current Hibernate 3.2.5.ga dependency) can overwrite dependency application has for newer EhCache ( http://forum.springframework.org/showthread.php?t=49956 ). If Hibernate would use 1.2.4+ EhCache there would be no need to specify separate EhCache dependency. -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5306) Dialect resolution: Cannot set a custom dialect resolver programatically or using hibernate.cfg.xml

by Nikita D (JIRA)

Dialect resolution: Cannot set a custom dialect resolver programatically or using hibernate.cfg.xml --------------------------------------------------------------------------------------------------- Key: HHH-5306 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5306 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1, 3.3.2 Reporter: Nikita D Priority: Minor Starting with version 3.3, Hibernate introduced an extremely useful dialect resolution feature (http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#por...). The problem is with the configuration of a custom dialect resolver: * Setting the property Environment.DIALECT_RESOLVERS in the Configuration of a SessionFactory doesn't work, because DialectFactory only reads from Environment.getProperties(), which is only the global properties (system properties plus the hibernate.properties file). * Setting a system property programatically is not safe, because the Environment class caches the system properties in a static constant, so if it's loaded before the code that sets the system property, the property will not be picked up. * The registerDialectResolver() method on DialectFactory is not public. Ideally, it should be possible to configure a custom dialect resolver by setting the property Environment.DIALECT_RESOLVERS on a Configuration object, just as one would configure an explicit dialect. Alternatively, I think an acceptable "quick fix" would be to expose the registerDialectResolver() method on DialectFactory. -- 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, 2 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4630) Criteria join on composite identifier generates wrong alias, SQL error

by Chris Wilson (JIRA)

Criteria join on composite identifier generates wrong alias, SQL error ---------------------------------------------------------------------- Key: HHH-4630 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4630 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: Hibernate trunk from 2009-11-30, Ubuntu 8.04, Sun Java 1.6.0-17, MySQL 5.0.51a-3ubuntu5.4 Reporter: Chris Wilson Attachments: hibernate-invalid-alias-generation.patch Hibernate generates the wrong alias on a Criteria query involving a join on a composite identifier. For example, in the test below without the fix to JoinWalker, it generates this SQL: select this_.role_code as role1_0_1_, this_.is_deleted as is2_0_1_, this_.record_version as record3_0_1_, complexjoi3_.code as code1_0_, complexjoi3_.is_deleted as is2_1_0_, complexjoi3_.record_version as record3_1_0_ from list_action_roles this_ left outer join roles complexjoi3_ on this_.role_code=complexjoi3_.code where this_.is_deleted=? and complexjoi1_.is_deleted=? Which results in this error from the SQL server: Unknown column 'complexjoi1_.is_deleted' in 'where clause' Analysis of the problem: The entity persister class with the composite identifier has a fake property for it, called "_identifierMapper" (see HbmBinder.bindCompositeId() and similarly in Annotations). This property name ends up in the path used by JoinWalker.walkEntityTree() when it calls walkComponentTree(). However that path is used by CriteriaJoinWalker.generateTableAlias() to look up the correct criteria (and hence the alias) from the translator, a CriteriaQueryTranslator. The alias was created in CriteriaQueryTranslator.createCriteriaSQLAliasMap for a Criteria without this extra _identifierMapper path component. So when CriteriaJoinWalker tries to use the path with _identifierMapper to look up the criteria to find the correct alias to use, in generateTableAlias(), it doesn't find one, so it generates a new alias. That new alias no longer matches the one that will be rendered out in the WHERE clause, so the WHERE clause will refer to table names using aliases that are not used anywhere else in the query, and the SQL server will fail to parse the statement. The solution appears to be to exclude "_identifierMapper" components in the alias path when building it. I don't know what other implications that might have, but it seems like an implementation nastiness that shouldn't be exposed. Patch 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, 2 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-35) Look for log and exception strategy

by Emmanuel Bernard (JIRA)

Look for log and exception strategy ----------------------------------- Key: HSEARCH-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-35 Project: Hibernate Search Type: Task Components: mapping, query, engine, directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.beta2 -- 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, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-210) Support hbm xml mapping!

by Mark Stewart (JIRA)

Support hbm xml mapping! ------------------------ Key: HSEARCH-210 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-210 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 3.0.1.GA Environment: All. Reporter: Mark Stewart I like annotations as much as the next guy but it's a complete non-starter for our business (and, I suspect, plenty of others) to add full text search to our existing apps via Hibernate Search if it means we must convert all our existing hbm.xml configurations into annotations. The regression testing alone would kill us. The Hibernate project has always been supremely pragmatic which is why I've filed this as a bug rather than a feature request. I don't think Hibernate would have been half as popular if it didn't support things like direct SQL and reverse engineering tools. I think Search would see a big boost if it could be easily added to existing applications. Please consider adding the needed syntax for xml mapping. At the very least an entry in the FAQ that explains the lacking is needed. -- 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, 2 months

6
11
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-373) @AnalyzerDiscriminator applied to _hibernate_class field

by Sanne Grinovero (JIRA)

@AnalyzerDiscriminator applied to _hibernate_class field -------------------------------------------------------- Key: HSEARCH-373 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-373 Project: Hibernate Search Issue Type: Bug Reporter: Sanne Grinovero It appears that implementations of org.hibernate.search.analyzer.Discriminator is also called to identify the Analyzer to be used to index the reserved "id" and "_hibernate_class". I'm not sure if it's a good idea on "id", it probably isn't at all on "_hibernate_class". -- 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, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-264) Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name)

by Emmanuel Bernard (JIRA)

Make a Luke version that can reuse Hibernate Search analyzers (per entity or per name) -------------------------------------------------------------------------------------- Key: HSEARCH-264 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-264 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Probably more on Hibernate Tools. Would be nice to fix copy/paste bugs too. -- 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, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-777) Map key column is included in the PK but is not forced not-null

by Emmanuel Bernard (JIRA)

Map key column is included in the PK but is not forced not-null --------------------------------------------------------------- Key: ANN-777 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-777 Project: Hibernate Annotations Issue Type: Bug Components: binder Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik I think forcing not-null is the right approach. This needs some investigation though -- 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, 2 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements

by Steve Finch (JIRA)

Include "FOR READ ONLY" hint in non-locking DB2 statements ---------------------------------------------------------- Key: HHH-3031 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Environment: 3.2.5, DB2/UDB 8.1+ Reporter: Steve Finch As per the DB2 documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i... The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning. For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements. A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY). The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified. Patch to be uploaded soon. -- 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, 2 months

5
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2010