May 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3905) Improve FieldInterceptionHelper perfomance

by Sergey Vladimirov (JIRA)

Improve FieldInterceptionHelper perfomance ------------------------------------------ Key: HHH-3905 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3905 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Sergey Vladimirov Priority: Minor Attachments: patch.txt do not iterate over interfaces, use Class.isAssignableFrom -- 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, 6 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5262) Allow UserType and CompositeUserType to be registered with BasicTypeRegistry

by Steve Ebersole (JIRA)

Allow UserType and CompositeUserType to be registered with BasicTypeRegistry ---------------------------------------------------------------------------- Key: HHH-5262 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5262 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 The implication here is that CustomType and CompositeCustomType need to (1) derive from the BasicType interface and (2) allow the user to configure the registration keys. 2 options for registration keys: # new (optional) interface, RegisterableUserType # allow passing the keys during registration via Configuration -- 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, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5268) Support for java.util.UUID properties/generators

by Steve Ebersole (JIRA)

Support for java.util.UUID properties/generators ------------------------------------------------ Key: HHH-5268 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5268 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.x See discussion on dev mailing list : http://lists.jboss.org/pipermail/hibernate-dev/2010-May/005209.html -- 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, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections

by Justin Haddad (JIRA)

Deleted object remains referenced in 2nd level cache collections ---------------------------------------------------------------- Key: HHH-1989 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3 Reporter: Justin Haddad This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object): aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102] at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871) at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839) at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101) at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48) at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705) (continues on) I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion. -- 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, 6 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5228) In Envers, retrieve only the most recent revision for all entities of a particular type

by Edwin Tellman (JIRA)

In Envers, retrieve only the most recent revision for all entities of a particular type --------------------------------------------------------------------------------------- Key: HHH-5228 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5228 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.3.2 Environment: any Reporter: Edwin Tellman Priority: Minor I would like to retrieve the most recent version of everything that has changed since a specified revision. This is useful for keeping one application synchronized with another. One system polls the other and the second system provides the current state of things that have changed recently. This query fetches everything that has changed since the specified revision: AuditQuery query = auditReader.createQuery() .forRevisionsOfEntity(entityClass, false, true) .add(AuditEntity.revisionNumber().gt(revision)) If I add a maximize restriction on the revision number, I get a single item which changed at the highest revision number, which isn't what I'm looking for. You could find the right data in SQL or HQL by grouping by ID and then selecting the maximum revision from each group. And, of course, I can use the above query and then filter out the older items from the result in Java, which is what I'm doing now. -- 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, 6 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3075) Should be possible to register UserTypes for known property types (classes) in configuration

by Martin Probst (JIRA)

Should be possible to register UserTypes for known property types (classes) in configuration -------------------------------------------------------------------------------------------- Key: HHH-3075 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3075 Project: Hibernate3 Issue Type: Improvement Components: core Environment: n/a Reporter: Martin Probst Priority: Minor Currently, when persisting primitive properties of a class that are not known to Hibernate, there are only cumbersome ways to tell Hibernate that a certain UserType should be used. Good example is Joda Time: <pre> @Entity class MyClass { org.joda.time.DateTime foo; } </pre> .. which will result in ugly binary fields in database. Next try: <pre> @Entity class MyClass { @Type(type = "org.joda.time.contrib.hibernate.PersistentDateTime") org.joda.time.DateTime foo; } </pre> That works, but now I have to specify that on all time fields of all classes. Plus it's different types for different classes, which makes it more messy. And it's simply a string in code, so it's fragile to refactoring, code move, etc. TypeDefs allow a shorter handle for certain types, but don't really address the refactoring issues. A better way might be to allow configurations to register UserTypes for known classes. E.g. have a configuration directive like this: <mappable-type class="org.joda.time.DateTime" usertype="org.joda.time.hibernate.DateTimeType"/> This would allow the classes to stay clean from type mappings and reduce coupling between domain objects and persistence mapping. This might be as easy as allowing the org.hibernate.type.TypeFactory map to be extended at configuration time. -- 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, 6 months

3
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-13) Fetch groups

by Sebastien Tardif (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-13?page=com... ] Sebastien Tardif commented on HHH-13: ------------------------------------- GK said: the "fetch group" notion does not work with annotations You can see an annotation example here: http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/r... > Fetch groups > ------------ > > Key: HHH-13 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-13 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc3 > Reporter: Adrien > > I don't like JDO at all, but it may have a good feature : the fetch groups. Instead of saying in each request which relations (or property now) I want to be fetch, I could says which fetch groups I want to be loaded. I will be usefull for complex objects will lot of relationship. Each fetch group will represent a view to the object. > from Contract c > left join fetch c.customer > left join fetch c.items > left join fetch c.foo > ==> > from Contract c > left join fetch c.fetchGroup1 > with : > <many-to-one name="customer" fetch-group="fetchGroup1" /> > <set name="items" fetch-group="fetchGroup1, fetchGroup2" > > <many-to-one name="foo" fetch-group="fetchGroup1" /> > > Adrien -- 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, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5279) Performance: a lot of time is spent getting and setting the auto-commit flag. Suggest it be configurable

by Phillip Henry (JIRA)

Performance: a lot of time is spent getting and setting the auto-commit flag. Suggest it be configurable -------------------------------------------------------------------------------------------------------- Key: HHH-5279 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5279 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.5.2 Environment: Seen in Hibernate 3.2 but appears to still be in Trunk Reporter: Phillip Henry Priority: Minor In org.hibernate.transaction.JDBCTransaction, a call to getAutoCommit is made on the connection at the start of the transaction and if it returns true, a setAutoCommit(true) is made after Hibernate has finished. These calls may be network calls (they certainly are with Sybase JConnect 5.5 drivers. They may be with others as well) and they are done in the same thread as that executing my INSERT/UPDATE commands. This means that about 25% of the time spent making a simple Session.saveOrUpdate is spent on something that is not important to me (in my application, I am not sharing the connection pool with other services so I don't care about the auto-commit status of connections when they are in the pool). It would be nice if I could speed up my application a little by setting an optional flag that indicates to JDBCTransaction whether it should care or not about the state of the connection when it has finished with it. Or, to have this work done by another thread. See http://javaagile.blogspot.com/2010/05/hibernate-and-performance-tuning.html for YourKit profiles. -- 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, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5278) Wrong parsing of hql/ejbql query

by ron piterman (JIRA)

Wrong parsing of hql/ejbql query -------------------------------- Key: HHH-5278 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5278 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.3.2 Reporter: ron piterman Attachments: hibtest.tar.gz Hibernate parses following query, ignoring superfluous parentheses and rules after: FROM Parent AS p WHERE p.id = ? ) AND p.child is null Attached is a test which should not pass. -- 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, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HV-326) Verify that for caching user objects during the validation process we use a IdentityHashMap or IdentityHashSet

by Emmanuel Bernard (JIRA)

Verify that for caching user objects during the validation process we use a IdentityHashMap or IdentityHashSet -------------------------------------------------------------------------------------------------------------- Key: HV-326 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-326 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.0.1.GA Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik Fix For: 4.1.0 -- 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, 7 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2010