February 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5661) Redesign the Hibernate metamodel

by Steve Ebersole (JIRA)

Redesign the Hibernate metamodel -------------------------------- Key: HHH-5661 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5661 Project: Hibernate Core Issue Type: Bug Components: metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Alpha1 Grouping task for redesigning the Hibernate metamodel -- 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

12 years, 9 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5672) Develop the binding model (binding between logical and relational)

by Steve Ebersole (JIRA)

Develop the binding model (binding between logical and relational) ------------------------------------------------------------------ Key: HHH-5672 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5672 Project: Hibernate Core Issue Type: Sub-task Reporter: Steve Ebersole -- 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

12 years, 9 months

2
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL

by Don Smith (JIRA)

No standard way to calculate date intervals in HQL -------------------------------------------------- Key: HHH-2434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: All Reporter: Don Smith Priority: Minor Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code. I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case. -- 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

12 years, 9 months

6
16
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

12 years, 9 months

2
2
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

12 years, 9 months

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

12 years, 9 months

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

12 years, 9 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)

by Steve Ebersole (JIRA)

Registration of IdentifierGenerators (short naming) --------------------------------------------------- Key: HHH-3512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512 Project: Hibernate Core Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4, 4.x Another way to look at this is to allow configuration of IdentifierGeneratorFactory. Either allow explicit registration under a short name in config: <identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/> or via an explicit contract: public interface Registerable { public String getRegistrationName(); } public class SequenceStyleGenerator implements IdentifierGenerator, Registerable { ... public String getRegistrationName() { return "sequence-style"; } } The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc). -- 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

12 years, 9 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5383) Register only one JTA sync from Hibernate

by Steve Ebersole (JIRA)

Register only one JTA sync from Hibernate ----------------------------------------- Key: HHH-5383 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5383 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 Currently, in the case of JTA-based transactions, org.hibernate.Transaction#registerSyncronization delegates the sync registration to the JTA transaction. The problem is that JTA/JTS do not require ordering of the sync callbacks -- 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

12 years, 9 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J

by Alan Krueger (JIRA)

EntityType.deepCopy needs to copy for EntityType.DOM4J ------------------------------------------------------ Key: HHH-2764 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: Alan Krueger Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that. Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent. -- 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

12 years, 9 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2011