February 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HBX-909) empty transaction manager should be allowed to override jpa stuff

by Max Rydahl Andersen (JIRA)

empty transaction manager should be allowed to override jpa stuff ----------------------------------------------------------------- Key: HBX-909 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-909 Project: Hibernate Tools Type: Improvement Components: consoleconfiguration Versions: 3.2beta9 Reporter: Max Rydahl Andersen Fix For: 3.2beta10 hibernate.transaction.manager_lookup_class is always instantiated even though its empty or not needed. to workaround this current hibernate behavior we need to provide a fake tx manager lookup so it can be overriden. -- 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

17 years, 10 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2452) Should accept empty properties as "not there" to allow overriding of providers etc.

by Max Rydahl Andersen (JIRA)

Should accept empty properties as "not there" to allow overriding of providers etc. ----------------------------------------------------------------------------------- Key: HHH-2452 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2452 Project: Hibernate3 Type: Improvement Versions: 3.2.2 Reporter: Max Rydahl Andersen Priority: Critical currently hibernate blindly tries to instantiate empty strings as connection providers, tx manager lookup etc. resulting in errors. This might be ok behavior, but it makes it impossible to actually override settings found in cfg.xml and-or persistence.xml (relevant for tooling to allow using war or ear configurations in tooling) I suggest we make hibernate ignore empty strings for these settings (or maybe all) to allow proper overriding -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2340) Entity second level cache put operations should either fail silently or provider to retry

by Galder Zamarreno (JIRA)

Entity second level cache put operations should either fail silently or provider to retry ----------------------------------------------------------------------------------------- Key: HHH-2340 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2340 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.1 Reporter: Galder Zamarreno Using JBossCache as second level cache and optimistic locking, rollbacks can still happen in systems under load as concurrent transactions could be modifying data in the cache. Hibernate clients could retry the update, but it's probably better if either, a similar silent failover mechanism was used for entity cache, or alternatively, Hibernate to attempt a retry. -- 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

17 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2450) SessionImpl.setReadOnly and SessionImpl.contains() inconsisten wrt handling proxied entities

by Ken Logan (JIRA)

SessionImpl.setReadOnly and SessionImpl.contains() inconsisten wrt handling proxied entities -------------------------------------------------------------------------------------------- Key: HHH-2450 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2450 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Reporter: Ken Logan There doesn't seem to be a correct way to use Session.setReadOnly() when working with possibly detatched and proxied objects. This is because SessionImpl.setReadOnly() doesn't unwrap the proxied object in the same fashion as SessionImpl.contains() does. Passing in a proxied object to SessionImpl.setReadOnly() seems to always result in a TransientObjectException even for this code: if(session.contains(myProxiedObject)) { session.setReadOnly(myProxiedObject, false); // throws TransientObjectException if myProxiedObject is really proxied } This is because SessionImpl.contains has special code to check the underlying object in the case of a proxy. -- 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

17 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1582) PostInsertListener + "post-commit-insert"

by Lucian Holland (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=c... ] Lucian Holland commented on HHH-1582: ------------------------------------- Ok, great. Thanks for the info. > PostInsertListener + "post-commit-insert" > ----------------------------------------- > > Key: HHH-1582 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Reporter: Daniel Gredler > Fix For: 3.3 > > Original Estimate: 3 hours > Remaining: 3 hours > > I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option. > As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed. > Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!). -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1582) PostInsertListener + "post-commit-insert"

by Emmanuel Bernard (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=all ] Emmanuel Bernard updated HHH-1582: ---------------------------------- Fix Version: 3.3 > PostInsertListener + "post-commit-insert" > ----------------------------------------- > > Key: HHH-1582 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Reporter: Daniel Gredler > Fix For: 3.3 > > Original Estimate: 3 hours > Remaining: 3 hours > > I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option. > As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed. > Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!). -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1582) PostInsertListener + "post-commit-insert"

by Emmanuel Bernard (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=c... ] Emmanuel Bernard commented on HHH-1582: --------------------------------------- Yes, this is an issue and you should use a Transaction synchronization instead (as I did for Hibernate Search). Compatibility issue speaking, we will probably fix that for 3.3 > PostInsertListener + "post-commit-insert" > ----------------------------------------- > > Key: HHH-1582 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Reporter: Daniel Gredler > Fix For: 3.3 > > Original Estimate: 3 hours > Remaining: 3 hours > > I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option. > As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed. > Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!). -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-869) Querying collections of value type in the Criteria API

by Emmanuel Bernard (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-869?page=co... ] Emmanuel Bernard commented on HHH-869: -------------------------------------- Providing a good patch + test will certainly increase the chances :) > Querying collections of value type in the Criteria API > ------------------------------------------------------ > > Key: HHH-869 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-869 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.1 beta 1 > Reporter: Alexey Kaigorodov > Priority: Minor > > > Please add support querying against values in a collection of values in the Criteria API. > Related links: > http://forum.hibernate.org/viewtopic.php?t=932908 > http://forum.hibernate.org/viewtopic.php?t=943792 > http://forum.hibernate.org/viewtopic.php?t=946236 > Best regards, > Alexey -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-566) Generate identical column aliases among cluster

by Loïc LEFEVRE (JIRA)

Generate identical column aliases among cluster ----------------------------------------------- Key: ANN-566 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-566 Project: Hibernate Annotations Type: Improvement Versions: 3.2.0.ga Environment: Hibernate version: 3.2.2, 2.1.8 Database: Oracle 9.2.0.8 Reporter: Loïc LEFEVRE Attachments: report_1.txt, report_2.txt Among our weblogic cluster, we can see that a query can have different column aliases. Although all seems correct, when regarding database reports like StatsPack or Spotlight we can see that because of these different aliases, the reports are wrong. Indeed, a resource consuming query can see its associated report properties (cpu usage, buffer gets, number of executions...) divided by the number of weblogic instances of our cluster (i.e. divided by 12) thus preventing us to pinpoint the queries to look at. As an example (on a 3 instances cluster), we can see these reports: REPORT#1: one statement with a poor number of buffer gets/execution is reported splitted in 3, see the alias generated for column DTO.CREATION_DATE for example REPORT#2: one statement responsible of the latch free/cache buffers chains wait events splitted in 4, note the column alias generated fordeffcashcy0_.BEST_EXPECTED_CY More than confusing the DBAs about the same query with n different "faces", our reports don't show us all the queries to look at: indeed, in our "Top 50 queries", a lot of them are duplicates! Also the memory required in the SGA to store the queries, the execution plan and so on is increased... Finally, although the column aliases can have up to 30 characters under Oracle, the limit is set to 10, why? -- 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

17 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-1582) PostInsertListener + "post-commit-insert"

by Lucian Holland (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=c... ] Lucian Holland commented on HHH-1582: ------------------------------------- I have had pretty much exactly the same issue... it does seem wrong that this event is fired even when the insert is not committed. Would a hibernate dev comment on what the intention was here? > PostInsertListener + "post-commit-insert" > ----------------------------------------- > > Key: HHH-1582 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Reporter: Daniel Gredler > > Original Estimate: 3 hours > Remaining: 3 hours > > I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option. > As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed. > Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!). -- 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

17 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2007