November 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-680) Clarify the documentation around date bridges and that they are using DateTools

by Hardy Ferentschik (JIRA)

Clarify the documentation around date bridges and that they are using DateTools ------------------------------------------------------------------------------- Key: HSEARCH-680 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-680 Project: Hibernate Search Issue Type: Task Components: documentation Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Fix For: 3.4.0 See also https://forum.hibernate.org/viewtopic.php?f=9&t=1009427 Maybe also time to implement some of the todos in {{DateBridge}} * allow pattern like yyyyMMdd? * allow base timezone? -- 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
7
0 / 0

[Hibernate-JIRA] Commented: (HHH-993) Criteria subquery without projection fails throwing NullPointerException

by Joachim Durchholz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-993?page=co... ] Joachim Durchholz commented on HHH-993: --------------------------------------- This is particularly annoying since SubqueryExpression#createAndSetInnerQuery's method comment indicates that this is just prefetching data that it assumes will be needed later. And, yes, it just bit me. And I'm not going to comment on how long this has been lying dormant. > Criteria subquery without projection fails throwing NullPointerException > ------------------------------------------------------------------------ > > Key: HHH-993 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-993 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Johannes Rudolph > Priority: Minor > > If you use a subquery in a criteria query and there is no projection, the execution of the query will fail by throwing a NullPointerException: > Caused by: java.lang.NullPointerException > at > org.hibernate.loader.criteria.CriteriaQueryTranslator.getProjectedTypes(Crit > eriaQueryTranslator.java:298) > at > org.hibernate.criterion.SubqueryExpression.toSqlString(SubqueryExpression.ja > va:56) > at > org.hibernate.criterion.LogicalExpression.toSqlString(LogicalExpression.java > :39) > org.hibernate.loader.criteria.CriteriaQueryTranslator.getWhereCondition(Crit > eriaQueryTranslator.java:314) > ... > I think it is expected behaviour that restrictions only work on 1-dimensional return values of subqueries so it would be nice if Hibernate would mention that somewhere. > It would be nice if you could just write: > Criteria crit = dbSession.createCriteria(Bla.class); > DetachedCriteria detachedCrit = DetachedCriteria.forClass(Blub.class).add( Restrictions.eq("condition", Boolean.FALSE)); > crit.add( Restrictions.or( Restrictions.isNull("superBlub"), > Subqueries.in("superBlub", detachedCrit ) ) ); > since Hibernate entities could be seen as "entities" so Hibernate should automatically transform it into: > DetachedCriteria detachedCrit = DetachedCriteria.forClass(Blub.class).add( Restrictions.eq("condition", Boolean.FALSE)) > .setProjection( Projections.id() ); > crit.add( Restrictions.or( Restrictions.isNull("superBlub"), > Subqueries.propertyIn("ueberPartner", detachedCrit ) ) ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-732) Add hibernate-entitymanager and javassist as optional dependencies in the distribution

by Emmanuel Bernard (JIRA)

Add hibernate-entitymanager and javassist as optional dependencies in the distribution -------------------------------------------------------------------------------------- Key: HSEARCH-732 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-732 Project: Hibernate Search Issue Type: Task Reporter: Emmanuel Bernard Fix For: 3.5 I tried quickly to hack dist.xml but Maven was yelling like a puppy MODULE BINARIES MAY NOT BE AVAILABLE FOR THIS ASSEMBLY! To refactor, move this assembly into a child project and use the flag <useAllReactorProjects>true</useAllReactorProjects> in each moduleSet. [INFO] Processing sources for module project: org.hibernate:hibernate-search:jar:3.4.0-SNAPSHOT [WARNING] NOTE: Currently, inclusion of module dependencies may produce unpredictable results if a version conflict occurs. [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'org.hibernate:hibernate-entitymanager' [WARNING] [DEPRECATION] moduleSet/binaries section detected in root-project assembly. MODULE BINARIES MAY NOT BE AVAILABLE FOR THIS ASSEMBLY! -- 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

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6808) Versionning problem in case of autoFlush required inside an "onSave" interceptor

by Romain Fromi (JIRA)

Versionning problem in case of autoFlush required inside an "onSave" interceptor -------------------------------------------------------------------------------- Key: HHH-6808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6808 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.6 Environment: Hibernate 3.5.6, Oracle Reporter: Romain Fromi I have an interceptor "onSave" for an Entity. I try to make a query with hibernate inside this onSave. The following exception is thrown : java.lang.NullPointerException at org.hibernate.type.IntegerType.next(IntegerType.java:82) at org.hibernate.engine.Versioning.increment(Versioning.java:131) at org.hibernate.event.def.DefaultFlushEntityEventListener.getNextVersion(DefaultFlushEntityEventListener.java:406) at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:296) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:155) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58) at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1175) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1699) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:347) at org.springframework.orm.hibernate3.HibernateTemplate$36.doInHibernate(HibernateTemplate.java:1056) at org.springframework.orm.hibernate3.HibernateTemplate$36.doInHibernate(HibernateTemplate.java:1) at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) ... As you can see, my query triggers an auto flush, because I try to read some objects related to the object currently saved (I cannot access these related objects another way, some relations are not bidirectionnal). During this auto flush, I have a null pointer inside Versioning.increment because the EntityEntry has a null version, whereas my entity has a version. I think that the version inside my own entity is not already reported inside the EntityEntry - the proof is in the stack trace before the onSave call: ... at org.hibernate.event.def.AbstractSaveEventListener.substituteValuesIfNecessary(AbstractSaveEventListener.java:414) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:293) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:210) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:195) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:117) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93) at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:677) ... As you can see, AbstractSaveEventListener.substituteValuesIfNecessary calls my method. But this method also process versionning : 398 /** 399 * Perform any property value substitution that is necessary 400 * (interceptor callback, version initialization...) 401 * 402 * @param entity The entity 403 * @param id The entity identifier 404 * @param values The snapshot entity state 405 * @param persister The entity persister 406 * @param source The originating session 407 * 408 * @return True if the snapshot state changed such that 409 * reinjection of the values into the entity is required. 410 */ 411 protected boolean substituteValuesIfNecessary( 412 Object entity, 413 Serializable id, 414 Object[] values, 415 EntityPersister persister, 416 SessionImplementor source) { 417 boolean substitute = source.getInterceptor().onSave( 418 entity, 419 id, 420 values, 421 persister.getPropertyNames(), 422 persister.getPropertyTypes() 423 ); 424 425 //keep the existing version number in the case of replicate! 426 if ( persister.isVersioned() ) { 427 substitute = Versioning.seedVersion( 428 values, 429 persister.getVersionProperty(), 430 persister.getVersionType(), 431 source 432 ) || substitute; 433 } 434 return substitute; 435 } "Versioning.seedVersion" is called after "source.getInterceptor().onSave" Maybe the version should have already been reported inside the EntityEntry when calling onSave ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3404) Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2)

by Geoffrey De Smet (JIRA)

Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2) ---------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3404 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3404 Project: Hibernate3 Issue Type: New Feature Components: query-hql Affects Versions: 3.2.6 Reporter: Geoffrey De Smet Hibernate 2 supported the rlike boolean operator (at least for mysql): HB-1034. Hibernate3 currently doesn't. It turns out that most mainstream databases support regular expression patterns (independently from normal like patterns). Mysql: rlike where a.serial rlike '\d*' Informix: regexp_match() where regexp_match(a.serial, '\d*') Oracle: REGEXP_LIKE where REGEXP_LIKE(a.serial, '\d*') There have been several forum posts asking about this feature for hibernate3 btw: http://forum.hibernate.org/viewtopic.php?p=2391395 http://forum.hibernate.org/viewtopic.php?p=2375634 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, 6 months

6
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-926) Duplicate InfinispanDirectoryProviders created when multiple sub-classes share the same index directory

by Zach Kurey (JIRA)

Duplicate InfinispanDirectoryProviders created when multiple sub-classes share the same index directory ------------------------------------------------------------------------------------------------------- Key: HSEARCH-926 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-926 Project: Hibernate Search Issue Type: Bug Components: directory provider, infinispan Affects Versions: 3.4.1.Final Reporter: Zach Kurey InfinispanDirectoryProvider doesn't implement hashCode/equals. When multiple subclasses of the same type share the same index directory duplicates are created. The end result from an application perspective leads to duplicate search results, and lots of side effects like: java.io.FileNotFoundException: Error loading medatada for index file: _b.fnm|M|Location at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:300) The errors and duplicates go away after overriding hashCode/equals based on directoryProviderName -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration

by Helmut Pasch (JIRA)

Envers hbm xml based configuration ---------------------------------- Key: HHH-3887 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.5 Environment: Hibernate: All Hibernate Versions including Envers as subproject Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, .... Reporter: Helmut Pasch Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans. We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier. Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation. -- 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
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6768) Hibernate Search archetype resolver generated ${project.version} as org.hibernate:hibernate-search-analyzers version

by Karel Piwko (JIRA)

Hibernate Search archetype resolver generated ${project.version} as org.hibernate:hibernate-search-analyzers version -------------------------------------------------------------------------------------------------------------------- Key: HHH-6768 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6768 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 4.0.0.CR1 Reporter: Karel Piwko When an archetype is generated, following dependency is managed by dependencyManagement in hibernate-search-parent. However, the version is not resolved to 4.0.0.CR1 but to actual project version, which is likely 1.0-SNAPSHOT (the default) {code} <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-analyzers</artifactId> </dependency> {code} Following error happens: {code} [INFO] Building Hibernate Search Quickstart 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] >>> maven-archetype-plugin:2.1:generate (default-cli) @ hibernate-search-quickstart >>> [WARNING] The POM for org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT is missing, no dependency information available [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 12.977s [INFO] Finished at: Tue Oct 25 14:52:46 CEST 2011 [INFO] Final Memory: 6M/116M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project hibernate-search-quickstart: Could not resolve dependencies for project org.jboss.wfk.hibernate.search:hibernate-search-quickstart:jar:1.0-SNAPSHOT: Failure to find org.hibernate:hibernate-search-analyzers:jar:1.0-SNAPSHOT in https://repository.jboss.org/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExce... {code} Workaround: Include version by yourself -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5525) Convert Getting Started Guide to use DocBook 5

by Steve Ebersole (JIRA)

Convert Getting Started Guide to use DocBook 5 ---------------------------------------------- Key: HHH-5525 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5525 Project: Hibernate Core Issue Type: Task Components: documentation Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6.0.CR1 This may require work on jDocBook to support, not sure. For sure we will need a docbook 5 bundle for maven respoitory -- 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

2
13
0 / 0

[Hibernate-JIRA] Created: (HHH-6804) "unable to locate static metamodel field" caused by MetadataContext.applyIdMetadata(PersistentClass, EntityTypeImpl)

by Karl Rhenius (JIRA)

"unable to locate static metamodel field" caused by MetadataContext.applyIdMetadata(PersistentClass, EntityTypeImpl) -------------------------------------------------------------------------------------------------------------------- Key: HHH-6804 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6804 Project: Hibernate Core Issue Type: Bug Components: metamodel Affects Versions: 4.0.0.CR5, 3.6.3 Environment: Hibernate 3.6.3 Reporter: Karl Rhenius Attachments: hibernate_issue.zip Hello, Hibernate throws the following error on startup: MetadataContext.registerAttribute:421 - Unable to locate static metamodel field : org.foo.test.inheritance.singlePk.MoviePoster_#posterId The entity MoviePoster is a subclass of the entity Poster. Poster uses the @IdClass annotation to define a primary key class and has a field posterId tagged with @Id After some debugging I found this piece of code in MetadataContext, that adds the property of my id class to the metadata-list of MoviePoster, because the id class has only one property: Line 251: else { final KeyValue value = persistentClass.getIdentifier(); if (value instanceof Component ) { final Component component = ( Component ) value; if ( component.getPropertySpan() > 1 ) { //FIXME we are an Hibernate embedded id (ie not type) } else { //FIXME take care of declared vs non declared property jpaEntityType.getBuilder().applyIdAttribute( attributeFactory.buildIdAttribute( jpaEntityType, (Property) component.getPropertyIterator().next() ) ); } } } I'm not quite sure, if this is a bug or improvement, because I couldn't find any problems so far. This bug seems to be related to HHH-5024, but the testcases are quite different. The attached file contains a testcase with a single-column and multi-column id-class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 November 2011