[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Douglas A. Herrick commented on HHH-2112: ----------------------------------------- We're running into the same 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Douglas A. Herrick commented on HHH-2112: ----------------------------------------- Steve, While perhaps not directly related to the other issue you and I have been discussing, it would seem that if you, effectively, disabled snapshots (like I did by specifying Query.setReadOnly(true)), but actually changed a persistent object that you resolved, would that result in the behavior this bug describes? -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Douglas A. Herrick commented on HHH-2112: ----------------------------------------- I looked into this today: for us, it was bit of a red herring; however, I thought other might be interested the root cause of our snafu... In our case, the object that triggered the hibernate exception during flush processing (for us, this occurred when hibernate executed a flush before resolving a query) had not assigned a reference to an object that would have satisified a foreign key constraint. Actually, I'd argue that, in this context, that is, flushing before executing a query, hibernate should not barf the way it did, since execution of the query was not dependend upon the assignment of the foreign key. While flush processing during commit might warrant this exception (since the foreign key constraint would have failed), preprocessing (i.e., flushing) for the query does not. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Nicklas Nordborg commented on HHH-2112: --------------------------------------- I get the same exception when doing Map.remove(). The map is lazy and hasn't been initialised. If I first to Map.containsKey() the Map.remove() returns the correct object and doesn't throw a ClassCastException. The Map object is defined using generics: Map<Integer, ReporterListScore> and I expect the Map.remove() method to return a ReporterListScore object but it returns a MarkerObject. I am now using Hibernate 3.2.1. This is a new problem. I was using 3.2.0.cr3 before. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=all ] Steve Ebersole resolved HHH-2112: --------------------------------- Fix Version: 3.2.2 Resolution: Fixed Assign To: Steve Ebersole Still have not seen a test case for this "bug". So I just made a small change to throw a more meaningful exception if getCachedDatabaseSnapshot() encounters a NO_ROW. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Steve Ebersole commented on HHH-2112: ------------------------------------- Also, I needed to remove the StringBuffer#indexOf call you were using as that is only available as of JDK 1.4... -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=all ] Steve Ebersole updated HHH-2112: -------------------------------- Comment: was deleted -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2112?page=c... ] Dobes Vandermeer commented on HHH-2112: --------------------------------------- I'm also seeing this issue with Map.remove(), this might be the issue (see the comments I added) but I can't prove anything yet. /** * @see java.util.Map#remove(Object) */ public Object remove(Object key) { if ( isPutQueueEnabled() ) { Object old = readElementByIndex( key ); // returns MarkerObject UNKNOWN if the object isn't in the map // add if(old == UNKNOWN) return null; queueOperation( new Remove( key, old ) ); return old; } else { // TODO : safe to interpret "map.remove(key) == null" as non-dirty? initialize( true ); if ( map.containsKey( key ) ) { dirty(); } return map.remove( key ); } } -- 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