July 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6445) Integrate new metamodel into SchemaUpdate

by Gail Badner (JIRA)

Integrate new metamodel into SchemaUpdate ----------------------------------------- Key: HHH-6445 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6445 Project: Hibernate Core Issue Type: Sub-task 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

14 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6517) MOre consistent naming in org.hibernate.metamodel.source.hbm.jaxb.mapping

by Steve Ebersole (JIRA)

MOre consistent naming in org.hibernate.metamodel.source.hbm.jaxb.mapping ------------------------------------------------------------------------- Key: HHH-6517 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6517 Project: Hibernate Core Issue Type: Improvement Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next Some use {{XYZSource}}, others {{XYZElement}}, and for good measure there is even {{MetaAttributeContainer}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

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

14 years, 4 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-6388) Bind filters that are specific to an EntityBinding

by Gail Badner (JIRA)

Bind filters that are specific to an EntityBinding -------------------------------------------------- Key: HHH-6388 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6388 Project: Hibernate Core Issue Type: Task Components: metamodel Reporter: Gail Badner Fix For: 4.0.0.next Filters should be bound using EntityBinding.addFilterDefinition(FilterDefinition). -- 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

14 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6434) Rename o.h.metamodel.relational.Schema

by Steve Ebersole (JIRA)

Rename o.h.metamodel.relational.Schema -------------------------------------- Key: HHH-6434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6434 Project: Hibernate Core Issue Type: Improvement Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next Rename to avoid confusion with "schema" when talking about schema/catalog config values. To be honest though, not really sure of a better name -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
3
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

14 years, 4 months

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

14 years, 4 months

3
4
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

14 years, 4 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

14 years, 4 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

14 years, 4 months

2
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2011