March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7150) evictAll() method is missing in SessionFactory getCache()

by Madhumita Sadhukhan (JIRA)

evictAll() method is missing in SessionFactory getCache() --------------------------------------------------------- Key: HHH-7150 URL: https://hibernate.onjira.com/browse/HHH-7150 Project: Hibernate ORM Issue Type: Improvement Components: core Affects Versions: 4.0.1 Reporter: Madhumita Sadhukhan Assignee: Strong Liu I was trying to test HHH-7016 in non-jpa API(i.e using Sessionfactory instead of EntityManagerFactory) but found that evictAll() is simply not supported by SessionFactory. I feel this is quite a convenience method to evict everything from secondlevelcache and will be nice to have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-321) FSSlaveDirectoryProvider incorrectly creates a subdirectory named 0

by Emmanuel Bernard (JIRA)

FSSlaveDirectoryProvider incorrectly creates a subdirectory named 0 ------------------------------------------------------------------- Key: HSEARCH-321 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-321 Project: Hibernate Search Issue Type: Bug Components: directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.1.1 I see a few areas where 0 is set on current. It probably comes from that. -- 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, 2 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7149) Lack of logging during import script

by Constantine (JIRA)

Lack of logging during import script ------------------------------------ Key: HHH-7149 URL: https://hibernate.onjira.com/browse/HHH-7149 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0, 4.0.0.Final Reporter: Constantine In 3.6 log exists http://grepcode.com/file/repo1.maven.org/maven2/org.hibernate/hibernate-c... In 4.0+ not http://grepcode.com/file/repository.springsource.com/org.hibernate/com.sp... So, we can't know broken filename. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6483) Add addJar() and addClassesFromPackage() to EntityManagerFactoryBuilder

by Ondra Žižka (JIRA)

Add addJar() and addClassesFromPackage() to EntityManagerFactoryBuilder ----------------------------------------------------------------------- Key: HHH-6483 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6483 Project: Hibernate Core Issue Type: New Feature Components: entity-manager Affects Versions: 4.0.0.next Reporter: Ondra Žižka JPA's persistence.xml has <jar-file> : {code} <persistence> <persistence-unit name="TestPU"> <jta-data-source>java:/TestDS</jta-data-source> <jar-file>foo/bar/entities.jar</jar-file> </persistence-unit> </persistence> {code} It would be fine to have Ejb3Configuration.addClassesFromJar() with the same effect. Also, Ejb3Configuration.addClassesFromPackage() would be handy, which would find package-info.class and scan it's place (dir, jar, ...) for entities (assuming a package is in one place only). After HHH-6159, they would be EntityManagerFactoryBuilder.addClassesFromJar() and EntityManagerFactoryBuilder.addClassesFromPackage(), respectively. Without this feature, users tend to hack their own scanning or use external lib like Scannotation, which is pitty since scanning code is already in Hibernate. Thanks for considering. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7148) Consider removing HibernateTypeDescriptor.isToOne along with getter and setter

by Gail Badner (JIRA)

Consider removing HibernateTypeDescriptor.isToOne along with getter and setter ------------------------------------------------------------------------------ Key: HHH-7148 URL: https://hibernate.onjira.com/browse/HHH-7148 Project: Hibernate ORM Issue Type: Task Reporter: Gail Badner Consider removing HibernateTypeDescriptor.isToOne along with getter and setter. I did not find any need for this when binding many-to-one associations or when integrating into persisters. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-640) use property names defined in CompositeUserType as default column names

by Michael Newcomb (JIRA)

use property names defined in CompositeUserType as default column names ----------------------------------------------------------------------- Key: ANN-640 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-640 Project: Hibernate Annotations Issue Type: New Feature Affects Versions: 3.3.0.ga Reporter: Michael Newcomb Priority: Minor Consider: public class LongitudeLatitude { protected double longitude; protected double latitude; } public class LongitudeLatitudeCompositeUserType implements CompositeUserType { public String[] getPropertyNames() { return new String[] { "longitude", "latitude" }; } public Type[] getPropertyTypes() { return new Type[] { Hibernate.DOUBLE, Hibernate.DOUBLE }; } ... } @Entity public class Test { @Basic(optional = false) @Type(type = "foo.bar.LongitudeLatitudeCompositeUserType") @Columns(columns = { @Column(name = "location_longitude"), @Column(name = "location_latitude") }) protected LongitudeLatitude location; } Why does the developer need to specify each column? I'd really rather let the CompositeUserType take care of that for me. Now, I have to tie the @Columns to the # of properties in my CompositeUserType AND the order in which they are defined? This seems to defeat the purpose of having a class (CompositeUserType) to tell Hibernate how to store it. Couldn't Hibernate prepend the property name 'location' and '_' to the front of each property name in the CompositeUserType? Perhaps (more than likely) I'm doing something wrong, but I get a failure if I do not specify the columns. Thanks, Michael -- 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, 2 months

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-7138) Hibernate implements JPA @OneToMany collection versioning incorrectly

by Uli Bubenheimer (JIRA)

Hibernate implements JPA @OneToMany collection versioning incorrectly --------------------------------------------------------------------- Key: HHH-7138 URL: https://hibernate.onjira.com/browse/HHH-7138 Project: Hibernate ORM Issue Type: Bug Affects Versions: 4.1.0, 3.6.8 Environment: Hibernate 4.1.0 or 3.6.8., SQL Server or H2 Database Engine Reporter: Uli Bubenheimer Attachments: H812NVersioningBug.zip Context: In my pure JPA-compliant app I have a bidirectional 1:n relationship expressed via a @ManyToOne foreign key on the child entity class, and a @OneToMany collection of children on the parent entity class. Both entity classes use optimistic locking via a @Version field. Problem: When I create a new child entity, and add the entity to the collection on the parent, the parent's version changes, causing OptimisticLockingException when concurrently creating child entities. As the parent is the non-owning side of the relationship, this violates the JPA spec. JPA 2.0 states the following (Section 3.4.2): bq.The version attribute is updated by the persistence provider runtime when the object is written to the database. *All non-relationship fields and properties and all relationships owned by the entity are included in version checks.* What the JPA spec says is reasonable, as the parent entity's associated DB record does not change at all in this case (besides the bad version increment). I am attaching a simple test case reproducing the problem. This was previously described here: http://stackoverflow.com/a/5259163 It looks like no defect was created at the time. A workaround, as mentioned in the article, is to specify @OptimisticLock(exclude = true) on the @OneToMany collection field. However, this pollutes a pure JPA app and makes it non-portable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-7147) ServiceRegistry is starting services twice

by Steve Ebersole (JIRA)

ServiceRegistry is starting services twice ------------------------------------------ Key: HHH-7147 URL: https://hibernate.onjira.com/browse/HHH-7147 Project: Hibernate ORM Issue Type: Bug Affects Versions: 4.1.0 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-4417) Add annotation support for UserCollectionType

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-4417?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-4417: ------------------------------------- The only sticking point with auto determination (and IIUC this exists today in the annotation code anyway) is if you have something like: {code:borderStyle=solid} public class UniqueList implements java.util.Set, java.util.List { ... } {code} If we need explicit specification of collection type (in the "Java type"/{{javax.persistence.metamodel.PluralAttribute.CollectionType}} sense) then I think: * that should be a separate issue (again it exists in the old existing code before these changes as well) * the solution should leverage org.hibernate.metamodel.domain.PluralAttributeNature, maybe exposed as an attribute on the {{org.hibernate.annotations.CollectionType}} annotation introduced by this issue, although TBH I think a separate annotation makes more sense. > Add annotation support for UserCollectionType > --------------------------------------------- > > Key: HHH-4417 > URL: https://hibernate.onjira.com/browse/HHH-4417 > Project: Hibernate ORM > Issue Type: Patch > Components: annotations > Environment: All versions, database agnostic > Reporter: Douglas Sjoquist > Assignee: Steve Ebersole > Priority: Minor > Fix For: 4.1.1 > > Attachments: UserCollectionTypeAnnotation.zip > > Original Estimate: 0.5h > Time Spent: 0.45h > Remaining Estimate: 0.5h > > Add an annotation to specify the UserCollectionType for a OneToMany or ManyToMany. > The annotation is named CollectionTypeInfo, perhaps better named UserCollectionType, but I didn't know the standards for naming classes. > The change to AnnotationBinder is minor and is delineated by '//dwsjoquist//' comment lines. > Usage: > @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL) > @JoinColumn(name = "id") > @CollectionTypeInfo(name = "examples.MyUserCollectionType") > public List<ExampleAttribute> getExampleAttributes() { -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-4417) Add annotation support for UserCollectionType

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-4417?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-4417: ------------------------------------- Even in {{hbm.xml}} binding, it is just assumed that whatever is named as a {{collection-type}} deals with the matching Java type named by the containing {{<list/>}}, {{<set/>}}, etc. As far as the corollary to determining difference between {{<list/>}}, {{<set/>}}, etc {{CollectionBinder}} on the annotation side already contains the appropriate logic. As Endre points out, there is a minor issue WRT the "Commons Annotations" stuff and/or the ReflectionManager where custom collection implementations (not the collection type implementations!) are not recognized as collections, even if the custom collection implementation extends a JDK one. So you have to expose this as a java collection ATM :( As an example: {code:borderStyle=solid} // given: class MyCustomList<X> implements java.util.List<X> { ... } // and: class MyCustomListType implements UserCollectionType { ... } // works fine @OneToMany(...) @CollectionType( type="MyCustomListType" ) public List getOrders() // erros due to mentioned limitation @OneToMany(...) @CollectionType( type="MyCustomListType" ) public MyCustomList getOrders() {code} > Add annotation support for UserCollectionType > --------------------------------------------- > > Key: HHH-4417 > URL: https://hibernate.onjira.com/browse/HHH-4417 > Project: Hibernate ORM > Issue Type: Patch > Components: annotations > Environment: All versions, database agnostic > Reporter: Douglas Sjoquist > Assignee: Steve Ebersole > Priority: Minor > Fix For: 4.1.1 > > Attachments: UserCollectionTypeAnnotation.zip > > Original Estimate: 0.5h > Time Spent: 0.45h > Remaining Estimate: 0.5h > > Add an annotation to specify the UserCollectionType for a OneToMany or ManyToMany. > The annotation is named CollectionTypeInfo, perhaps better named UserCollectionType, but I didn't know the standards for naming classes. > The change to AnnotationBinder is minor and is delineated by '//dwsjoquist//' comment lines. > Usage: > @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL) > @JoinColumn(name = "id") > @CollectionTypeInfo(name = "examples.MyUserCollectionType") > public List<ExampleAttribute> getExampleAttributes() { -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2012