September 2011 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-6538) Extract CollectionElement interface from AbstractCollectionElement

by Gail Badner (JIRA)

Extract CollectionElement interface from AbstractCollectionElement ------------------------------------------------------------------ Key: HHH-6538 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6538 Project: Hibernate Core Issue Type: Task Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-6559) Add support for providing SQL functions as service

by Gail Badner (JIRA)

Add support for providing SQL functions as service -------------------------------------------------- Key: HHH-6559 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6559 Project: Hibernate Core Issue Type: Task Components: core Reporter: Gail Badner Fix For: 4.0.0.next Should this be provided by JdbcServices? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6652) Add ability for Integrator to prepare MetadataImplementor as part of lifecycle

by Steve Ebersole (JIRA)

Add ability for Integrator to prepare MetadataImplementor as part of lifecycle ------------------------------------------------------------------------------ Key: HHH-6652 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6652 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6692) An Integrator cannot set NamingStrategy in the new Metamodel API (it's possible in Configuration)

by Emmanuel Bernard (JIRA)

An Integrator cannot set NamingStrategy in the new Metamodel API (it's possible in Configuration) ------------------------------------------------------------------------------------------------- Key: HHH-6692 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6692 Project: Hibernate Core Issue Type: Improvement Components: metamodel Affects Versions: 4.1.0 Reporter: Emmanuel Bernard {code} public class MyIntegrator implements Integrator, ServiceContributingIntegrator { @Override public void integrate(Configuration configuration, SessionFactoryImplementor sessionFactory, SessionFactoryServiceRegistry serviceRegistry) { configuration.setNamingStrategy( MyNamingStrategy.INSTANCE ); } @Override public void integrate(MetadataImplementor metadata, SessionFactoryImplementor sessionFactory, SessionFactoryServiceRegistry serviceRegistry) { //FIXME how to do it here? } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3348) loading context

by benjamin Leroux (JIRA)

loading context --------------- Key: HHH-3348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3348 Project: Hibernate3 Issue Type: New Feature Affects Versions: 4.x Reporter: benjamin Leroux Priority: Minor this proposal is for creating a loading context into hibernate Let me explain: On an application, we often hesitating between the two major strategies of loading (eager or lazy). But for some reason there has no good choice. In fact, it depends on the context. So we do lazy loading and redefine some method with new request with some "join". In fact, it lead to complexity and decrease managability of the application. So my idea is to allow the definition of a context (like transactional context) where we we can put the loading strategie to adopt. with annotation it could be very easy to define such context. Let see this exemple : Avec les annotations, cela pourrait conduire à une ecriture de ce style : @LoadingStrategie (type=eager from="Car" get={"driver"}) public List<Car> getAllCarForDriving(){ // Some fonctions } @LoadingStrategie (type=eager from="Car" get={"driver","passengers"}) public List<Car> getAllCarForTravelling(){ // Some fonctions } In the method getAllCarForDriving when we call a hql request on car it automaticaly get driver but in the method getAllCarForTravelling passengers and the driver is loaded. -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6228) Build is platform dependent

by Stevo Slavic (JIRA)

Build is platform dependent --------------------------- Key: HHH-6228 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6228 Project: Hibernate Core Issue Type: Patch Components: build Affects Versions: 4.x Environment: Windows 7 x64 Reporter: Stevo Slavic Priority: Trivial Attachments: Fixes+build%2C+compile+tasks+used+platform+encoding+making+build+platform+depend.patch Build tasks generateMainLoggingClasses and compileJava were failing because default platform encoding was used. -- 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

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6604) confusing error message when OneToOne has a duplicate on one end

by Laura Dean (JIRA)

confusing error message when OneToOne has a duplicate on one end ---------------------------------------------------------------- Key: HHH-6604 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6604 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.6, 4.x Environment: originally found with hibernate 3.6.6 and MS SQL Server; also happens when run in a hibernate unit test. Reporter: Laura Dean Priority: Minor Attachments: OneToOne-error-message.patch Suppose I have a Trousers entity with id 1, that knows about its TrousersZip, which has id 2. That is, my Trousers has zip_id = 2. (This part of the example comes from Hibernate's unit tests.) Suppose the Trousers has a TrousersHanger, also one-to-one, but mapped on the TrousersHanger side. That is, the hanger points to its Trousers. Now suppose I put two TrousersHangers into the database, both pointing at the same Trousers. (Naughty, I know; in the real world, it happened because of HHH-6484.) When I then try to load the Trousers from the database, I get a very confusing error message: org.hibernate.HibernateException: More than one row with the given identifier was found: 2, for class: org.hibernate.test.annotations.onetoone.Trousers The message confuses me for three reasons: 1. I have only one row in the Trousers table. 2. That one row has ID 1. 3. My actual problem is with duplicate TrousersHangers, and neither one of them has ID 2. In other words, where the heck did ID 2 come from? As it turns out, hibernate finds the Trousers by id, then finds the Trousers by zip_id (to populate the TrousersZip object). It doesn't care about the duplicate results in the first query, but it does care the second time. But the error message doesn't mention that its ID is actually the zip_id, and a person could waste quite a bit of time before figuring out that the TrousersZip had anything to do with it. (Well, maybe not in this contrived example with only 3 entities. But in the real world, yeah.) I've attached a junit test, adding to hibernate's own OneToOneTest. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5797) Improve batching for entity updates or deletes that use secondary tables

by Gail Badner (JIRA)

Improve batching for entity updates or deletes that use secondary tables ------------------------------------------------------------------------ Key: HHH-5797 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5797 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Gail Badner Fix For: 4.x Currently, batching is only used for update/delete statements made to an entity's primary table (subject to other conditions). Batching is not used for update/delete statements on secondary tables. 1) if an entity has *any* secondary tables with optional="true, do not use batching for updating/deleting any of the entity's (primary or secondary) tables 2) if all of an entity's secondary tables are non-optional (e.g. "joined" subclass, all "joined" tables have optional="false"), then use batching for updates/deletes to all (primary and secondary) tables -- 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
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode

by Steve Ebersole (JIRA)

Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode ------------------------------------------------------------------------ Key: HHH-5184 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Fix For: 3.6 Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker. The situation was: {code} class EJB1 { public void doSomething() { Session s = getCurrentSession(); ... ejb2.doSomethingElse(); // now use the HIbernate session } } class EJB2 { public void doSomethingElse() { Session s = getCurrentSession(); // Use the session in a way that requires a Connection... } } {code} What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated). At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead. So initially I see: ConnectionAcquisitionMode.AS_NEEDED ConnectionAcquisitionMode.IMMEDIATELY -- 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

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5551) Setting to enable envers rather than having to manually name listeners

by Steve Ebersole (JIRA)

Setting to enable envers rather than having to manually name listeners ---------------------------------------------------------------------- Key: HHH-5551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5551 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Steve Ebersole Fix For: 3.6.0.CR1 WDYT? -- 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
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2011