December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-917) DSL API doesn't build the correct Lucene query

by Guillaume Smet (JIRA)

DSL API doesn't build the correct Lucene query ---------------------------------------------- Key: HSEARCH-917 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-917 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.4.1.Final Reporter: Guillaume Smet Priority: Critical Hi, A bit of context: We are early adopters of Hibernate Search and we have very few problems with it (except the @IndexEmbedded problem we helped to fix in 3.4.1, no problem so far). When the DSL API was introduced, I tried it and I found the problem I describe below. I decided to use the QueryParser API (and the MultiFieldQueryParser API) as a workaround. The fact is that: * we use Hibernate Search in every application we have, now; * the DSL API is really nice and, as we introduced QueryDSL in our application, we now use a lot of DSL like API and I would like to be able to use Hibernate Search API too; * I thought it was a deliberate choice but, recently I found an example so weird, I can't think it's the wanted behaviour. So this problem isn't new and it exists since the first version of the DSL API. Now, the description of the problem: * we use the following analyzer to index a field in our entity: {code} @AnalyzerDef(name = HibernateSearchAnalyzer.TEXT, tokenizer = @TokenizerDef(factory = WhitespaceTokenizerFactory.class), filters = { @TokenFilterDef(factory = ASCIIFoldingFilterFactory.class), @TokenFilterDef(factory = WordDelimiterFilterFactory.class, params = { @org.hibernate.search.annotations.Parameter(name = "generateWordParts", value = "1"), @org.hibernate.search.annotations.Parameter(name = "generateNumberParts", value = "1"), @org.hibernate.search.annotations.Parameter(name = "catenateWords", value = "0"), @org.hibernate.search.annotations.Parameter(name = "catenateNumbers", value = "0"), @org.hibernate.search.annotations.Parameter(name = "catenateAll", value = "0"), @org.hibernate.search.annotations.Parameter(name = "splitOnCaseChange", value = "0"), @org.hibernate.search.annotations.Parameter(name = "splitOnNumerics", value = "0"), @org.hibernate.search.annotations.Parameter(name = "preserveOriginal", value = "1") } ), @TokenFilterDef(factory = LowerCaseFilterFactory.class) } ), {code} * the content of the field is something like XXXX-AAAA-HAGYU-19910 * if you search for an exact match "XXXX-AAAA-HAGYU-19910" with the QueryParser, you have a few results: namely the results which have all the different parts (XXXX, AAAA, HAGYU and 19910) in any order. That's the behaviour I expect considering my analyzer. * if you search using the DSL API, you have ALL the results containing at least ONE token so A LOT of results in our case. My expectation is that the DSL API should work as the Lucene parser works and it should return the same results. The problem is that in ConnectedMultiFieldsTermQueryBuilder, we don't use the QueryParser to build the Lucene query but a getAllTermsFromText() method which uses the analyzer to get all the terms and from that we build a OR query. So when I search for XXXX-AAAA-HAGYU-19910, the DSL API searches for "XXXX" OR "AAAA" OR "HAGYU" OR "19910". I really think it's a mistake and that we should use the *QueryParser API to build the Lucene Query and have the correct behaviour. If needed, I can provide any further information and/or a test case. I just want to be sure you consider it a bug before working further on this. Otherwise I'll stick to using the *QueryParser API. Thanks for your feedback. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HHH-5043) Incorrect handling of hibernate.default_schema in SchemaUpdate

by Vladimir Klyushnikov (JIRA)

Incorrect handling of hibernate.default_schema in SchemaUpdate -------------------------------------------------------------- Key: HHH-5043 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5043 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-CR-2 Environment: Hibernate Core 3.5.0-CR-2, Oracle 10.2 Reporter: Vladimir Klyushnikov Attachments: cfg.patch While HHH-735 fixes default_schema handling in general, it still has a bug. When SchemaUpdate reads foreign keys metainfo is doesn't honor default_schema and default_catalog settings. The fix is simple and patch is attached. -- 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, 5 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HV-411) Move LazyValidatorFactory into org.hibernate.validator.engine

by Hardy Ferentschik (JIRA)

Move LazyValidatorFactory into org.hibernate.validator.engine ------------------------------------------------------------- Key: HV-411 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-411 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Fix For: 4.x This class does not belong into the util package and also created an unnecessary package cycle. According to the classes docs it is used in JBoss AS 6. A move must be synced with the AS. -- 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, 5 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HV-532) Remove package cycle between "core" and "descriptor" packages

by Gunnar Morling (JIRA)

Remove package cycle between "core" and "descriptor" packages ------------------------------------------------------------- Key: HV-532 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-532 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.2.0.Final Reporter: Gunnar Morling Fix For: 4.3.0.next There is a cyclic dependency between the packages {{org.hibernate.validator.metadata.core}} and {{org.hibernate.validator.metadata.descriptor}} which should be removed. I think the general problem is that {{ConstraintDescriptorImpl}} (which is now part of the "descriptor" model) is used globally in HV. Probably there should be a corresponding node in the internal model (actually we already have this with {{MetaConstraint}}), of which {{ConstraintDescriptorImpl}} would only be a light-weight view for external meta-model users. In {{ConstraintDescriptorImpl}} there is also a lot of logic related to annotation retrieval, which we now might move into the provider hierarchy similar to {{BeanMetaDataImpl}}. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6502) Develop List-style plural attribute support for new metamodel

by Steve Ebersole (JIRA)

Develop List-style plural attribute support for new metamodel ------------------------------------------------------------- Key: HHH-6502 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6502 Project: Hibernate Core Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole 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

12 years, 6 months

2
4
0 / 0

[Hibernate-JIRA] Created: (ANN-728) @NaturalId doesn't work with @Embeddable/@Embedded

by Kenny MacLeod (JIRA)

@NaturalId doesn't work with @Embeddable/@Embedded -------------------------------------------------- Key: ANN-728 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-728 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Reporter: Kenny MacLeod Attachments: BugTestCase.java If I try to annotate an @Entity's field with @NaturalId, and that field happens to be @Embedded or @Embeddable, then hibernate barfs with org.hibernate.MappingException: Unable to find logical column name from physical name component in table BugTestCase$MyEntity at org.hibernate.cfg.Mappings.getLogicalColumnName(Mappings.java:514) at org.hibernate.cfg.IndexOrUniqueKeySecondPass.doSecondPass(IndexOrUniqueKeySecondPass.java:61) at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1136) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:324) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859) See attached unit test as a demonstration. Surely this is not an exotic scenario? Tested with Hibernate Core 3.2.6-GA -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HV-499) Add @URI validator to support relative URLs

by Ted Bergeron (JIRA)

Add @URI validator to support relative URLs ------------------------------------------- Key: HV-499 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-499 Project: Hibernate Validator Issue Type: New Feature Components: validators Affects Versions: 4.2.0.Final Reporter: Ted Bergeron Should be trivial to leverage the @URL logic to allow for relative URI's. -- 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
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level

by Don Smith (JIRA)

org.hibernate.event.def.DefaultLoadEventListener logs exception at info level ----------------------------------------------------------------------------- Key: HHH-2085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18 Reporter: Don Smith Priority: Minor Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution. Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener: catch(HibernateException e) { log.info("Error performing load command", e); throw e; } -- 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
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5964) IllegalArgumentException (Parameter value ... was not matching type ...) for JPA-Query: Worked with 3.3.1.GA

by Sebastian Hasait (JIRA)

IllegalArgumentException (Parameter value ... was not matching type ...) for JPA-Query: Worked with 3.3.1.GA ------------------------------------------------------------------------------------------------------------ Key: HHH-5964 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5964 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.1 Reporter: Sebastian Hasait We have switched from core-3.3.1.GA and entity-manager-3.4.0.GA to 3.6.1.Final. Now some queries stopped working. This is caused by an additional type check in org.hibernate.ejb.AbstractQueryImpl#registerParameterBinding@359 which does not care about hibernate-proxies. This method is called from QueryImpl#setParameter(...). This call doesn't exist in 3.4.0.GA. I think the proxies should be as transparent as possible. So if I get a proxy from some relation getter and put this into a query as parameter, there should be no exception. Because the proxy cannot know the concrete type without initializing the proxy-target (reading discriminator from database) there remain four solutions: 1.) Hibernate is not checking the type for proxies OR only ensures expected type and proxy-type are related. 2.) Hibernate initializes the parameter and the type checking works without exception. 3.) Our DAO initializes the parameter before passing. 4.) We rewrite our queries to pass only the PK I would prefer 1 or 2. :-) Will attach test case asap. -- 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

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5858) Cannot load entities with Clob or Lob properties into stateless sessions

by James Roper (JIRA)

Cannot load entities with Clob or Lob properties into stateless sessions ------------------------------------------------------------------------ Key: HHH-5858 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5858 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Reporter: James Roper I have a an entity with a Clob property: {code:java} @Lob private Clob clobProperty; {code} When I try and load it in a stateless session, I get: {noformat} Exception in thread "main" java.lang.ClassCastException: org.hibernate.impl.StatelessSessionImpl cannot be cast to org.hibernate.engine.jdbc.LobCreationContext at org.hibernate.Hibernate.getLobCreator(Hibernate.java:420) at org.hibernate.type.ClobType.nullSafeGet(ClobType.java:114) at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105) at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2267) at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1423) at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1351) at org.hibernate.loader.Loader.getRow(Loader.java:1251) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:619) at org.hibernate.loader.Loader.loadSingleRow(Loader.java:307) at org.hibernate.impl.ScrollableResultsImpl.prepareCurrentRow(ScrollableResultsImpl.java:254) at org.hibernate.impl.ScrollableResultsImpl.next(ScrollableResultsImpl.java:123) {noformat} If Lobs in stateless sessions isn't supported, then at very least an error message to that effect should be thrown and the docs should be updated to reflect this, but I don't see why that should be the case, especially considering that both Lobs and stateless session both serve very similar purposes, they are for use when dealing with large datasets that may not fit in memory, and so could well be used together. -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011