September 2006 - hibernate-issues

[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-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] Created: (EJB-221) TransientObjectException with FetchType.LAZY on @ManyToOne and field access on target entity

by Christian Bauer (JIRA)

TransientObjectException with FetchType.LAZY on @ManyToOne and field access on target entity -------------------------------------------------------------------------------------------- Key: EJB-221 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-221 Project: Hibernate Entity Manager Type: Bug Components: EntityManager Reporter: Christian Bauer Priority: Blocker Attachments: fetchtest.jar Latest SVN of everything: em = factory.createEntityManager(); em.getTransaction().begin(); Soldier2 soldier = em.find(Soldier2.class, mickey.getId()); System.out.println("### TRYING TO ACCESS PROXY ID..."); // This triggers a SELECT, it shouldn't System.out.println("### PROXY ID : " + soldier.getTroop().getId()); // This throws a TransientObjectException em.flush(); The @ManyToOne troop in Soldier2.java has only FetchType.LAZY, the CascadeType.PERSIST is removed. I expect the problem to be in CascadingAction PERSIST_ON_FLUSH.noCascade() somewhere, apparently the proxy has no Id anymore during flush-time and is considered transient (how can a proxy be transient?). The problems appear as soon as I move the annotations from getters to fields in Troop2.java. The attached tests are for HEM. -- 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
9
0 / 0

[Hibernate-JIRA] Created: (ANN-447) Introduce @WhereJoinTable to complete @Where on association involving a join table

by Emmanuel Bernard (JIRA)

Introduce @WhereJoinTable to complete @Where on association involving a join table ---------------------------------------------------------------------------------- Key: ANN-447 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-447 Project: Hibernate Annotations Type: New Feature Components: binder Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard Priority: Minor Fix For: 3.2.0 This break the use of @Where on @ManyToMany and @OneToMany @JoinTable -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HBX-767) generate meta in hbm2hbmxml

by Max Rydahl Andersen (JIRA)

generate meta in hbm2hbmxml ---------------------------- Key: HBX-767 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-767 Project: Hibernate Tools Type: New Feature Components: reverse-engineer Versions: 3.2beta8 Reporter: Max Rydahl Andersen Fix For: 3.2beta9 hbm2hbmxml should output <meta> attributes (but won't be able to represent inherit, so inherit="false" for all) -- 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
1
0 / 0

[Hibernate-JIRA] Created: (EJB-219) Add an EntityManagerFactory.getCurrentEntityManager() method.

by James Olsen (JIRA)

Add an EntityManagerFactory.getCurrentEntityManager() method. ------------------------------------------------------------- Key: EJB-219 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-219 Project: Hibernate Entity Manager Type: New Feature Components: EntityManager Environment: Hibernate 3.2. Any/All. Reporter: James Olsen BACKGROUND I'd like to code against the JPA standard, however my current EJB container vendor (like many others) is only providing JPA support as part of their EJB3 rollout which is at a very early stage. JPA doesn't need a full EJB3 environment. The only required apsect that appears to be missing in existing EJB containers is container management and injection of a correctly scoped EntityManager. I can deal with the injection problem by having a Singleton accessor for the EntityManagerFactory in much the same way as the well known HibernateUtil deals with the SessionFactory. All that is left then is providing something similar to the automatic JTA/CMT context scoping of Sessions for EntityManager instances. SUGGESTION I would propose that a new custom API be added to org.hibernate.ejb.EntityManagerFactoryImpl in the form of a method called getCurrentEntityManager(). Internally this would construct an EntityManagerImpl that was configured to do sessionFactory.getCurrentSession() rather than sessionFactory.openSession() (inside the getRawSession() method), thereby leveraging Hibernates pre-existing capability to return correctly scoped units of work in a JTA/CMT environment. Thats sounds easy, but maybe there's more to it!? JUSTIFICATION The advantage of having such an API is that we can write to the JPA API without waiting for full EJB3 support in the container. The little bit of application code to obtain the EntityManagerFactory, cast to the Hibernate impl and call this custom method can easily be removed in the future when EntityManager injection is available. I've looked at using Spring and Pitchfork but as great as they are, they are heavy handed when you already have a container and my customer demands a container and also has an aversion to non GA code (implies I'm confident the Hibernate 3.2 products will be GA soon - which I am!). -- 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] Commented: (HHH-1050) HQL Unions

by John C. Checco, CISSP (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1050?page=c... ] John C. Checco, CISSP commented on HHH-1050: -------------------------------------------- I would vote for implementing the entire resultset manipulation operations: UNION / UNION ALL MINUS / EXCEPT / EXCEPT ALL INTERSECT / INTERSECT ALL I have been working around the union/intersect problem by wrapping the HSQL statements separately and using the "IN" operator. The problem here is that each DB has its limits on how many elements can be used for the IN set (oracle has 10000, sqlsvr has 2000). i've run into this limit already so it would be great to have HQL support this. I also realize that not every DB implementation supports these operations, but I would expect the HQL engine to recognize that and replace it with runtime-based resultset manipulations. > HQL Unions > ---------- > > Key: HHH-1050 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1050 > Project: Hibernate3 > Type: New Feature > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.1 > > > Add the ability to define unions in HQL. Support will be initially limited to only: > 1) scalar queries : select id from Animal union select id from Car > 2) the same entity : from Animal where ... union from Animal where ... > Support both UNION and UNION ALL -- 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] Commented: (HHH-1813) 2nd level cached collections are locked causing a cache miss

by Erik Heckert (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1813?page=c... ] Erik Heckert commented on HHH-1813: ----------------------------------- Hi Assaf. Of course you are perfectly right. I've made some code investigation, and now I believe I have an idea of what goes wrong. org.hibernate.cache.ReadWriteCache has an internal class "Item". In Item's methode "isGettable" "freshTimestamp" and "txTimestamp" are compared. "freshTimestamp" is the point in time the item has been put into the cache. "txTimestamp" should be the point in time the transaction has begun. What a pity: "txTimestamp" is not only always < "freshTimestamp", it never changes! Have a look at "org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache (...)". Here the get-method of ReadWriteCache is called, and "txTimestamp" is the timestamp of the session, not the transaction! So, if you use session pooling (I do), ReadWriteCache will always fail for you, because txTimestamp does not advance. I think the transaction should have a timestamp which should be filled into the get method, but for the time being we need a work around: Simply do not pool your sessions, close them after the commit or rollback. This way your cache works. It does for me now. What do you think? > 2nd level cached collections are locked causing a cache miss > ------------------------------------------------------------ > > Key: HHH-1813 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1813 > Project: Hibernate3 > Type: Bug > Versions: 3.1 > Environment: Hibernate 3.1, Oracle 10g, Linux > Reporter: Assaf Berg > Priority: Critical > Attachments: testcase.tar.gz > > > Using the second level cache, collections are fetched from the database due to the cached item being locked. > This happens in the most simple use case: > 1. Insert an entity with a collection > 2. Commit. > 3. Fetch the entity > I've written a simple test case and see the following in the log file: > 11:52:47,159 DEBUG [ReadWriteCache] Invalidating: domain.Cat.kittens#539957 > 11:52:47,177 DEBUG [ReadWriteCache] Inserting: domain.Cat#539957 > 11:52:47,179 DEBUG [ReadWriteCache] Inserted: domain.Cat#539957 > 11:52:47,180 DEBUG [ReadWriteCache] Inserting: domain.Kitten#540214 > 11:52:47,180 DEBUG [ReadWriteCache] Inserted: domain.Kitten#540214 > 11:52:47,181 DEBUG [ReadWriteCache] Releasing: domain.Cat.kittens#539957 > 11:52:49,221 DEBUG [ReadWriteCache] Caching: domain.Cat#539957 > 11:52:49,221 DEBUG [ReadWriteCache] Item was already cached: domain.Cat#539957 > 11:52:49,223 DEBUG [ReadWriteCache] Cache lookup: domain.Cat.kittens#539957 > 11:52:49,223 DEBUG [ReadWriteCache] Cached item was locked: domain.Cat.kittens#539957 > 11:52:49,229 DEBUG [ReadWriteCache] Caching: domain.Kitten#540214 > 11:52:49,229 DEBUG [ReadWriteCache] Item was already cached: domain.Kitten#540214 > 11:52:49,230 DEBUG [ReadWriteCache] Caching: domain.Cat.kittens#539957 > 11:52:49,231 DEBUG [ReadWriteCache] Cached: domain.Cat.kittens#539957 > domain.Cat.kittens [C/H/M/P]: 1/0/1/1 > domain.Cat [C/H/M/P]: 1/0/0/1 > domain.Kitten [C/H/M/P]: 1/0/0/1 > This happens whether the collection is mapped as inverse or not. > I've attached the test case source and hbms (although it might need to be tweaked for the proper DB before running, and I didn't include the dependencies JARs). > Here's a code excerpt of the interesting part (tx is TransactionTemplate using HibnerateTransactionManager and hibernate is HibernateTemplate from the spring framework): > tx.execute(new TransactionCallback() { > public Object doInTransaction(TransactionStatus status) { > // create a Cat with one Kitten > Cat cat = new Cat(); > Kitten kitten = new Kitten(); > cat.addKitten(kitten); > > hibernate.save(cat); > > return null; > } > }); > > Thread.sleep(2000L); > > tx.execute(new TransactionCallback() { > public Object doInTransaction(TransactionStatus status) { > // load all cats > List<Cat> allCats = hibernate.loadAll(Cat.class); > return null; > } > }); > I can supply further information if 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

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 September 2006