September 2011 - hibernate-issues

[Hibernate-JIRA] Created: (HSEARCH-871) Only the last enabled FullTextFilter is in effect if multiple FullTextFilters of the same type, different parameters are enabled

by Elmer van Chastelet (JIRA)

Only the last enabled FullTextFilter is in effect if multiple FullTextFilters of the same type, different parameters are enabled -------------------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-871 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-871 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.4.0.Final Environment: - Reporter: Elmer van Chastelet Attachments: FilterTestAdded.diff The following test fails, it only seems to apply the last filter. Attached is a patch that adds this test and changes to the domain/filters. {code:java} ftQuery = s.createFullTextQuery( query, Driver.class ); ftQuery.enableFullTextFilter( "fieldConstraintFilter") .setParameter( "field", "teacher" ) .setParameter( "value", "andre" ); ftQuery.enableFullTextFilter( "fieldConstraintFilter") .setParameter( "field", "teacher" ) .setParameter( "value", "aaron" ); assertEquals("Should apply both filters resulting in 0 results", 0, ftQuery.getResultSize() ); {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6403) OneToOne not optional dependent entity wrong persist order

by Diego Salvi (JIRA)

OneToOne not optional dependent entity wrong persist order ---------------------------------------------------------- Key: HHH-6403 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6403 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.5 Environment: Tested with hibernate-core 3.6.3.Final and 3.6.5.Final, database MySQL 5.1 with InnoDB (for foreign key costraints) Reporter: Diego Salvi Attachments: hib_1to1_dependent_optional_false.tar.gz There's a problem with dependent entity persist order in a one to one relationship. Given 2 entity ParentEntity and DependentEntity in a relationship one to one and with the second one completely dependent from first (DependentEntity PK is ParentEntity PK) I can't set optional=false one ParentEntity relationship side. If optional=false is set on ParentEntity side DepententEntity will be persisted first but it can't because his PK is a FK to ParentEntity and it results in a constraint violation. I've tried to check why this happen and I think that the problem resides in a wrong assumption in: {code:title=OneToOneSecondPass.doSecondPass(Map persistentClasses)[lines 105:110]|borderStyle=solid} if ( !optional ) value.setConstrained( true ); value.setForeignKeyType( value.isConstrained() ? ForeignKeyDirection.FOREIGN_KEY_FROM_PARENT : ForeignKeyDirection.FOREIGN_KEY_TO_PARENT ); {code} This assumes that if relation isn't optional then foreign key goes from parent to child (ie.: parent has a field that point to a child field) that is at least a over-simplification. From this wrong direction come a wrong persisting order. Please be aware that a OneToOne bidirectional non optional relationship is't a silly and insane mapping and can be useful in many environment. It could be mapped as opional=true but then we have fetch problem because FetchType.LAZY can't be fulfilled. I've added a simple test case with 2 entity. It uses annotations and entity-manager (but the real problem is on core). Just change persistence.xml to match your db user and password and set to an empty schema (it is already set as create-drop). Failing test is: hib.test.PersistTest.persist() I'm listing most important entity mappings for quick reference (in attached test case are obviously complete), as you can see the are really simple (I've tried to use default as much as I could): {code:title=ParentEntity|borderStyle=solid} [...] @OneToOne( optional = false, cascade = CascadeType.PERSIST, mappedBy = "parentEntity" ) public DependentEntity getDependentEntity() { return dependentEntity; } [...] {code} {code:title=ParentEntity|borderStyle=solid} [...] @Id @GeneratedValue( generator="foreign" ) @GenericGenerator( name="foreign", strategy = "foreign", parameters = @Parameter( name="property", value="parentEntity" ) ) public Integer getId() { return id; } [...] @OneToOne( optional = false ) @PrimaryKeyJoinColumn public ParentEntity getParentEntity() { return parentEntity; } [...] {code} -- 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

13 years, 3 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-664) Create a mechanism to allow custom class and field bridges to specify analyzers for all fields added to document

by Hardy Ferentschik (JIRA)

Create a mechanism to allow custom class and field bridges to specify analyzers for all fields added to document ---------------------------------------------------------------------------------------------------------------- Key: HSEARCH-664 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-664 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Currently there is no easy way to specify which analyzer to use for custom fields added via class or custom field bridges. One work around is to write/use a custom scoped analyzer and use it in conjunction which the bridge. Another work around is the use of _@ClassBridges_ with mutiple _@ClassBridge_. Using the query DSL one has to use _overridesForField_ to overcome the issue at query time. A more detailed discussion of the issue can be found on the Search forum - https://forum.hibernate.org/viewtopic.php?f=9&t=1008943&start=0 Possible solutions are: * Extension of bridge api * Introduction of a concept similar to _AnalyzerDiscriminator_ which only operates on field names. _AnalyzerDiscriminator_ depends on the entity state and is really only used during indexing. At search time this concept cannot be used, because there is no actual instance to pass to the query -- 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

13 years, 3 months

2
4
0 / 0

[Hibernate-JIRA] Deleted: (HHH-6671) dffd

by Hardy Ferentschik (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6671?page=c... ] Hardy Ferentschik deleted HHH-6671: ----------------------------------- > dffd > ---- > > Key: HHH-6671 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6671 > Project: Hibernate Core > Issue Type: New Feature > Reporter: Prashant Shinde > Original Estimate: 6h > Remaining Estimate: 6h > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6673) @Embbeded fields updated in @PreUpdate not included in update when dynamicUpdate=true

by Tom Allison (JIRA)

@Embbeded fields updated in @PreUpdate not included in update when dynamicUpdate=true ------------------------------------------------------------------------------------- Key: HHH-6673 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6673 Project: Hibernate Core Issue Type: Bug Components: annotations, core Affects Versions: 3.6.7, 3.6.5 Environment: hibernate-core 3.6.5, 3.6.7, Oracle 10g Reporter: Tom Allison Attachments: TestCase.zip When using an @Embedded component for audit fields and setting the values in a @PreUpdate lifecycle method, the fields do not get included in the UPDATE statement when using @org.hibernate.annotations.Entity(dynamicUpdate = true). See attached test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6671) dffd

by Prashant Shinde (JIRA)

dffd ---- Key: HHH-6671 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6671 Project: Hibernate Core Issue Type: New Feature Reporter: Prashant Shinde -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6668) JaxbProcessor can't resolve hibernate-configuration-4.0.xsd

by Christian Bauer (JIRA)

JaxbProcessor can't resolve hibernate-configuration-4.0.xsd ----------------------------------------------------------- Key: HHH-6668 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6668 Project: Hibernate Core Issue Type: Bug Affects Versions: 4.0.0.CR3 Reporter: Christian Bauer Priority: Trivial This code in JaxbProcessor.java schema = resolveLocalSchema( "/org/hibernate/hibernate-configuration-4.0.xsd" ); should not use a leading slash, the result will always be null. I'm not sure if the schema-ified version of the config file should be used at all though, doesn't seem to be tested or documented. Or the ClassLoaderServiceImpl#locateResource(name) et al. methods should remove leading slashes of names. http://download.oracle.com/javase/1.5.0/docs/guide/lang/resources.html 'The methods in ClassLoader use the given String as the name of the resource without applying any absolute/relative transformation (see the methods in Class). The name should not have a leading "/".' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
4
0 / 0

[Hibernate-JIRA] Issue Comment Edited: (HHH-1570) criteria-api: filtering by key-many-to-one causes invalid sql

by Christian Priebe (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570?page=c... ] Christian Priebe edited comment on HHH-1570 at 9/20/11 6:09 AM: ---------------------------------------------------------------- Is there any hope this issue will ever get resolved? It seems like this is known (as missing feature or as bug) since 2003 ( see https://hibernate.onjira.com/browse/HB-417 ) was (Author: christian.priebe): Is there any hope this issue will ever get resolved? It seems like this is known (as missing feature or as bug) since 2003 ( see https://hibernate.onjira.com/browse/HB-417 ) Whoops, this should have been a comment referencing the issue and not the "changed assignment" message. Sorry for that! > criteria-api: filtering by key-many-to-one causes invalid sql > ------------------------------------------------------------- > > Key: HHH-1570 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570 > Project: Hibernate Core > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.5.3, 3.6.0.Beta1 > Reporter: Joris Verschoor > Assignee: Steve Ebersole > Attachments: HHH-1570-fix.patch, HHH-1570-it.patch, hibernate.patch > > > We have a class Price that has a composite-id using a couple of key-properties and some key-many-to-ones) > One of those is "transportation", which has a many-to-one to transportationType > When we query using: criteria.add(Expression.eq("price.transportation.transportationType.id", transId);, we get an invalid SQL statement: The table of transportation was not selected. > I will try to make a testcase today or tomorrow, depending on my schedule.. Things will be more clear by then... > We have created a work-around, by mapping the transportationID twice: once in key-property, and once as a many-to-one. (instead of one key-many-to-one) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Issue Comment Edited: (HHH-1570) criteria-api: filtering by key-many-to-one causes invalid sql

by Christian Priebe (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570?page=c... ] Christian Priebe edited comment on HHH-1570 at 9/20/11 6:09 AM: ---------------------------------------------------------------- Is there any hope this issue will ever get resolved? It seems like this is known (as missing feature or as bug) since 2003 ( see https://hibernate.onjira.com/browse/HB-417 ) Whoops, this should have been a comment referencing the issue and not the "changed assignment" message. Sorry for that! was (Author: christian.priebe): Is there any hope this issue will ever get resolved? It seems like this is known (as missing feature or as bug) since 2003 ( see https://hibernate.onjira.com/browse/HB-417 ) > criteria-api: filtering by key-many-to-one causes invalid sql > ------------------------------------------------------------- > > Key: HHH-1570 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570 > Project: Hibernate Core > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.5.3, 3.6.0.Beta1 > Reporter: Joris Verschoor > Assignee: Steve Ebersole > Attachments: HHH-1570-fix.patch, HHH-1570-it.patch, hibernate.patch > > > We have a class Price that has a composite-id using a couple of key-properties and some key-many-to-ones) > One of those is "transportation", which has a many-to-one to transportationType > When we query using: criteria.add(Expression.eq("price.transportation.transportationType.id", transId);, we get an invalid SQL statement: The table of transportation was not selected. > I will try to make a testcase today or tomorrow, depending on my schedule.. Things will be more clear by then... > We have created a work-around, by mapping the transportationID twice: once in key-property, and once as a many-to-one. (instead of one key-many-to-one) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1570) criteria-api: filtering by key-many-to-one causes invalid sql

by Christian Priebe (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570?page=c... ] Christian Priebe commented on HHH-1570: --------------------------------------- Is there any hope this issue will ever get resolved? It seems like this is known (as missing feature or as bug) since 2003 ( see https://hibernate.onjira.com/browse/HB-417 ) > criteria-api: filtering by key-many-to-one causes invalid sql > ------------------------------------------------------------- > > Key: HHH-1570 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1570 > Project: Hibernate Core > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.5.3, 3.6.0.Beta1 > Reporter: Joris Verschoor > Assignee: Steve Ebersole > Attachments: HHH-1570-fix.patch, HHH-1570-it.patch, hibernate.patch > > > We have a class Price that has a composite-id using a couple of key-properties and some key-many-to-ones) > One of those is "transportation", which has a many-to-one to transportationType > When we query using: criteria.add(Expression.eq("price.transportation.transportationType.id", transId);, we get an invalid SQL statement: The table of transportation was not selected. > I will try to make a testcase today or tomorrow, depending on my schedule.. Things will be more clear by then... > We have created a work-around, by mapping the transportationID twice: once in key-property, and once as a many-to-one. (instead of one key-many-to-one) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 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 September 2011