October 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (ANN-408) map a entity to integer map is not possible

by Armin Haaf (JIRA)

map a entity to integer map is not possible ------------------------------------------- Key: ANN-408 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-408 Project: Hibernate Annotations Type: Bug Versions: 3.2.0.cr1 Reporter: Armin Haaf It is not possible to map a entity to integer map: Map<MyClass, Integer> myMap; -- 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, 7 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2064) Delete not always executing

by Jasper Rosenberg (JIRA)

Delete not always executing --------------------------- Key: HHH-2064 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2064 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Environment: MySQL (latest stable), XP/Linux, hibernate 3.2.0.cr4, Spring 2.0-rc3 Reporter: Jasper Rosenberg This case I just ran into works in 3.1.3 but fails in 3.2.0 Release Candidates (1-4). In a single JTA transaction I execute unit test: personManager.save(firstName, lastName, email, phone, password); Person person = personManager.get(email); // Not the PK assertNotNull(person); personManager.delete(person); // Deletes by PK person = personManager.get(email); // Not the PK assertNull(person); personManager is just a DAO that uses a Spring HibernateTemplate to call save/delete/get on the underlying Session. In 3.1.3, the final "assertNull(person)" succeeds. In 3.2-RC4 it fails Also, if I replace that final get with: person = personManager.get(person.getId()); // Get by PK Then the assertion succeeds. When I turn on logging for org.hibernate.SQL, I can see in 3.2-RC4 the delete is never executed (unlike in 3.1.3). If I had to make a total guess, I would suspect that in 3.2-RC4 the delete it only getting applied to the session cache, and never making it to the database for some reason. Then, since the get(email) is not by primary key, it skips the cache (where it has been removed) and finds it still in the database. Sorry I am unable to give you a discrete case you can run to reproduce this issue (there are a stupid number of dependencies), but hopefully this case will trigger a lightbulb to go off for the developer who was last working in this portion of the 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

17 years, 7 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2134) i was working in JSF hibernate along with the jboss server 4.0.4ga.I was getting an error periodically,that is "could not register JTA transaction"

by Maheshkumar Duraisamy (JIRA)

i was working in JSF hibernate along with the jboss server 4.0.4ga.I was getting an error periodically,that is "could not register JTA transaction" --------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2134 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2134 Project: Hibernate3 Type: Bug Components: query-hql Versions: 3.2.0.ga Environment: postgresql is the database,hibernate version is Reporter: Maheshkumar Duraisamy The error was not coming all the time.Its sometimes not coming and at that time the datas are inserted,updated etc.,Can you give a solution to this problem -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2133) Enable basic temporal collection iteration pattern

by Christian Bauer (JIRA)

Enable basic temporal collection iteration pattern -------------------------------------------------- Key: HHH-2133 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2133 Project: Hibernate3 Type: Improvement Components: core Reporter: Christian Bauer Priority: Minor Attachments: temporalpattern.zip I've tried to implement a basic temporal pattern with Hibernate and failed when it came to collection iteration with applied temporal filters. This is an interesting problem: the challenge is to map a read-only collection to an arbitrary join with partly dynamic values. My attempts to use property-ref and filters weren't successful. We might need to extend the abilities of property-ref to include key-properties as targets. See the attached example app to see what I'm up to. Also read this: http://en.wikipedia.org/wiki/Temporal_database -- 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, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2129) Invalid column name SQL Error: 17006, SQLState: null

by sagar patkar (JIRA)

Invalid column name SQL Error: 17006, SQLState: null ---------------------------------------------------- Key: HHH-2129 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2129 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.cr3 Environment: Hibernate 3.2 cr3 with oracle 9i Reporter: sagar patkar Hi, Is it required that stored procedure must return all the column in the resultset of the mapped class. i was trying to fetch only subset of column & i got the following exception ERROR [org.hibernate.util.JDBCExceptionReporter] - <Invalid column name> is it a bug? or is there any alternative solution for this? Stored procedure CREATE OR REPLACE PACKAGE BODY Pkg_Test2 IS PROCEDURE get_my_list(p_record OUT ref_cur ,eventid IN NUMBER) AS BEGIN OPEN p_record FOR SELECT EVENT_ID, TITLE FROM EVENTS WHERE EVENT_ID=eventid; END get_my_list; END Pkg_Test2; / mapping file for procedure call <sql-query name="test_select_sp" callable="true"> <return alias="evaa" class="events.Event"> <return-property name="id" column="EVENT_ID"/> <return-property name="title" column="TITLE"/> </return> { call pkg_test1.get_selected_list(?,:eventid)} </sql-query> -- 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, 7 months

3
5
0 / 0

[Hibernate-JIRA] Updated: (HHH-1891) Since rc3 deprecation Warning: The syntax 'TYPE=storage_engine' is deprecated and will be removed in MySQL 5.2.

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1891?page=all ] Steve Ebersole updated HHH-1891: -------------------------------- Fix Version: 3.2.0.cr5 (was: 3.2.0.ga) > Since rc3 deprecation Warning: The syntax 'TYPE=storage_engine' is deprecated and will be removed in MySQL 5.2. > --------------------------------------------------------------------------------------------------------------- > > Key: HHH-1891 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1891 > Project: Hibernate3 > Type: Bug > Versions: 3.2.0.cr3 > Environment: I use MySQL 5.1.11-bata on Windows XP. > mysql-connector-java-3.1.13-bin.jar > My settings: > hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect > hibernate.connection.driver_class com.mysql.jdbc.Driver > Reporter: Stefan Bühlmann > Assignee: Scott Marlow > Priority: Minor > Fix For: 3.2.0.cr5 > Attachments: MySQL5InnoDBDialect.patch > > > Since cr3 I get the following warning (cr2 goes without it): > 09.07.2006 11:10:11 org.hibernate.tool.hbm2ddl.SchemaExport execute > INFO: exporting generated schema to database > 09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings > WARNUNG: SQL Warning: 1541, SQLState: HY000 > 09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings > WARNUNG: The syntax 'TYPE=storage_engine' is deprecated and will be removed in MySQL 5.2. Please use 'ENGINE=storage_engine' instead. > 09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings > WARNUNG: SQL Warning: 1541, SQLState: HY000 -- 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, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2093) PERSIST_ON_FLUSH ineffective for recursive object graphs

by Max Rydahl Andersen (JIRA)

PERSIST_ON_FLUSH ineffective for recursive object graphs -------------------------------------------------------- Key: HHH-2093 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2093 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.cr4 Reporter: Max Rydahl Andersen Assigned to: Max Rydahl Andersen cascade for PERSIST_ON_FLUSH does not keep track on what cascades have already been performed. Resulting in a big performance penalty for graphs that has recursive associations since every association will result in a "full go-deep" cascade. -- 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, 7 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2103) Rolling back 'SELECT is mandatory' on JPA strict compliance

by Emmanuel Bernard (JIRA)

Rolling back 'SELECT is mandatory' on JPA strict compliance ----------------------------------------------------------- Key: HHH-2103 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2103 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.cr4 Reporter: Emmanuel Bernard Priority: Minor TCK changes to allow that -- 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, 7 months

2
2
0 / 0

[Hibernate-JIRA] Updated: (HHH-1668) PersistentSet write methods mark collection as dirty even if entry is not written

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1668?page=all ] Steve Ebersole updated HHH-1668: -------------------------------- Fix Version: 3.2.0.cr5 (was: 3.2.1) > PersistentSet write methods mark collection as dirty even if entry is not written > --------------------------------------------------------------------------------- > > Key: HHH-1668 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1668 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3 > Reporter: Koda Janh > Assignee: Steve Ebersole > Fix For: 3.2.0.cr5 > Attachments: PersistentList.patch, PersistentSet.patch, hhh-1668.tests.txt > > Original Estimate: 5 minutes > Remaining: 5 minutes > > PersistentSet gets marked as dirty even if it hasn't changed. This has negative implications for concurrency because the optimistic-lock version is incremented and StaleObjectStateException is thrown even if the underlying data remains unchanged. > I stepped through the code and narrowed down the problem to a bug in PersistentSet.add(). A simple fix is to replace: > if (exists==null) { > write(); > return set.add(value); > } > by: > if (exists==null) { > boolean result = set.add(value); > if (result) { > write(); > } > return result; > } > I verified that this fixed the problem on my end. The old code was always marking the Set as dirty whereas the new code only does so if it actually has been modified. Please commit this patch. -- 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, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1714) Session.get() behavior

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1714?page=all ] Steve Ebersole updated HHH-1714: -------------------------------- Fix Version: 3.2.0.cr5 (was: 3.2.1) > Session.get() behavior > ---------------------- > > Key: HHH-1714 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1714 > Project: Hibernate3 > Type: Bug > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0.cr5 > > > The behavior of Session.get() should be as follows: > 1) if the entity to get is already associated with the session: > a) as a proxy, return the proxy making sure it gets initialized (potentially resulting in a ONFE) > b) as a naked entity, return that entity > 2) if the entity to get is not already associated with the session, attempt to load it either returning null if not found or the "naked" loaded entity > Currently (1.a) is messed up in that the proxy is returned but not forced to initialize -- 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, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2006