October 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6705) SQL datatypes for booleans not being handled correctly

by Steve Ebersole (JIRA)

SQL datatypes for booleans not being handled correctly ------------------------------------------------------ Key: HHH-6705 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6705 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR4 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next Perhaps due to changes for metamodel... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2774) Call ResultTransformer.transformList() even if the list argument is an empty list

by Christian Bauer (JIRA)

Call ResultTransformer.transformList() even if the list argument is an empty list --------------------------------------------------------------------------------- Key: HHH-2774 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2774 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Christian Bauer Priority: Trivial I have a case where a ResultTransformer is doing all the work in transformTuple() and always returns null from that method. The transformed target state is held internally in the ResultTransformer instance (I basically turn many tuples into one). Now I can't get this state out of the ResultTransformer because transformList() is not called after transformTuple(). It would be better if transformList() is called even if the list of tuples returned by transformTuple() is empty. -- 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, 6 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6680) 2L caching appears to ignore collections

by Ben Hood (JIRA)

2L caching appears to ignore collections ---------------------------------------- Key: HHH-6680 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6680 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.6.7 Environment: 3.6.7 on Derby 10.8.1.2 and Oracle 11g Reporter: Ben Hood I have a scenario where a (read-mostly) mapped collection is eagerly loaded with the parent object, but when I retrieve the graph, the 2L cache appears to get ignored and the data is hydrated from the DB. I have created a test case to reproduce this issue as a runnable Maven project on Github : https://github.com/0x6e6562/hibernate_2L -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6609) Provide a way to supply prebuild ConnectionProvider to Hibernate

by Christoph Läubrich (JIRA)

Provide a way to supply prebuild ConnectionProvider to Hibernate ---------------------------------------------------------------- Key: HHH-6609 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6609 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.6.7 Reporter: Christoph Läubrich Currently it is only possible to provide a ConnectionProvider via the property Environment.CONNECTION_PROVIDER which only accepts a class-name which later is instantiated via ConnectionProviderFactory: private static ConnectionProvider initializeConnectionProviderFromConfig(String providerClass) { ConnectionProvider connections; try { log.info( "Initializing connection provider: " + providerClass ); connections = (ConnectionProvider) ReflectHelper.classForName( providerClass ).newInstance(); } catch ( Exception e ) { log.error( "Could not instantiate connection provider", e ); throw new HibernateException( "Could not instantiate connection provider: " + providerClass ); } return connections; } This aproch is okay for connectionprovider which are very generic and can build up completely by the configuration, but under some circumstances the creation and setup is out of scope of the Provider implementation class. For this case it would be helpfull to have a configuration property like Environment.CONNECTION_PROVIDER_REFERENCE and a static public Method in the ConnectionProviderFactory like ConnectionProviderFactory.addConnectionProviderReference(ConnectionProvider provider, String reference) So it would be possible to make something like this: ConnectionProvider provider = new MySpecialProvider(x, y, z); provider.doSpecialSetup(d); ConnectionProviderFactory.addConnectionProviderReference(provider, "MySpecialProvider"); . . . Configuration configuration = new Configuration(); configuration.setProperty(Environment.CONNECTION_PROVIDER_REFERENCE, "MySpecialProvider"); SessionFactory factory = configuration.buildSessionFactory(); The only alternative to this in current days is to create a ConnectionProvider class which completely relies on static setup methods, making the code relativly complicated and error prone, as well as introducing class not found problems if the provider is not in the same class loader context as hibernate or the module which creates the configuration (for example in OSGi applications). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6716) envers should set the TCCL to the envers classloader before constructing a dom4j instance. This will allow applications to use their own version of dom4j

by Scott Marlow (JIRA)

envers should set the TCCL to the envers classloader before constructing a dom4j instance. This will allow applications to use their own version of dom4j --------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-6716 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6716 Project: Hibernate Core Issue Type: Improvement Components: envers Reporter: Scott Marlow Fix For: 4.0.0.next forum link http://community.jboss.org/message/630480 Envers set TCCL to be envers's module classloader before constructing a dom4j instance. This will allow applications to use their own version. Also see http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide section on "How to use JAXP and other service provider APIs from AS/Framework code". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-902) Shutdown should not log a warning about forcing the index lock release

by Sanne Grinovero (JIRA)

Shutdown should not log a warning about forcing the index lock release ---------------------------------------------------------------------- Key: HSEARCH-902 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-902 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha3 This used to be a warning as we do the same as part of error handling on an IndexWriter, but should not happen during normal shutdown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-941) Update JBoss Logger to 3.0.1.GA

by Sanne Grinovero (JIRA)

Update JBoss Logger to 3.0.1.GA ------------------------------- Key: HSEARCH-941 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-941 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.CR1 and the annotation processor too, especially as it changed name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6713) Lazy by context

by Martin Krüger (JIRA)

Lazy by context --------------- Key: HHH-6713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6713 Project: Hibernate Core Issue Type: New Feature Components: caching (L2) Reporter: Martin Krüger Sometimes I want to load references lazy and sometimes not. For example, if I read some object for a table, i need less information, if I look at the details. A workaround for this, is to implement lightweight entities, or fetch all referenced entities by calling a.getAllB().size() if attribute b were lazy. Would it be possible to steer lazy during runtime, rather then design time? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6712) Bulk Insert/Delete

by Martin Krüger (JIRA)

Bulk Insert/Delete ------------------ Key: HHH-6712 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6712 Project: Hibernate Core Issue Type: New Feature Components: core Affects Versions: 4.0.0.CR4 Reporter: Martin Krüger Deletion with cascade is done object by object now. When entity A references entity B and one deletes several objects A, then b1 is deleted then a1, b2 then a2, and so on. It would be more performant if the bulk operation first deletes all b's and then deletes all a's. This could be done by collecting the id's of the entities and then delete all entries in one table. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6708) Loading parent/child entities with foreign key in child table being its primary key results in StackOverflowError

by Florian Rampp (JIRA)

Loading parent/child entities with foreign key in child table being its primary key results in StackOverflowError ----------------------------------------------------------------------------------------------------------------- Key: HHH-6708 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6708 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.6 Environment: HSQL 1.8.0.10 (also reproducible with Oracle 11g, with Oracle JDBC 11.2.0.1.0 Reporter: Florian Rampp Attachments: bugreports-hibernate-cascadeAll-1.0-SNAPSHOT-src.zip Consider the following parent/child relationship mapping: {code:java} @Entity public class Parent { @Id Long id; // @OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE, CascadeType.REFRESH, // CascadeType.DETACH }, orphanRemoval = true, mappedBy = "parent") @OneToOne(cascade = CascadeType.ALL, orphanRemoval = true, mappedBy = "parent") Child child; void setChild(Child child) { this.child = child; child.setParent(this); } } @Entity public class Child implements Serializable { @Id @OneToOne(optional = false) private Parent parent; public void setParent(Parent parent) { this.parent = parent; } } {code} When storing a parent with a child and loading it again, the load results in a StackOverflowError. When I replace the cascade type {{ALL}} with a list of all cascade types {{\{CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE, CascadeType.REFRESH, CascadeType.DETACH\}}}, the error does not occur any more. I attached a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2011