May 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2638) SchemaUpdate asks for all referenced mapping documents when updating a single table

by bhomass (JIRA)

SchemaUpdate asks for all referenced mapping documents when updating a single table ----------------------------------------------------------------------------------- Key: HHH-2638 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2638 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.2.0 cr1 Environment: myql, Reporter: bhomass I believe the idea of doing schema update is so that you can update a single table with a single property. However, as I try this feature out, hibernate continues to throw exception because this table I want to update refers to an unmapped class. I can move to the next step by adding another map file, but then more and more unmapped classes get involved, and pretty soon, I am feeding the entire collection of map files. So that's no different from updating the entire database. I think it should be possible automatically read out the existing schema of the referenced tables from the database, so that their mapping files don't need to be supplied to SchemaUpdate, and these referenced tables do not inadvertently get updated too (with no net effect of course). -- 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

17 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (ANN-122) Add natural-id annotation

by Nicolás Lichtmaier (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-122?page=co... ] Nicolás Lichtmaier commented on ANN-122: ---------------------------------------- You don't seem to be doing that in bindManyToOne(), in fact you are not passing the XProperty as a parameter there. I could pass it... > Add natural-id annotation > ------------------------- > > Key: ANN-122 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-122 > Project: Hibernate Annotations > Issue Type: New Feature > Components: binder > Affects Versions: 3.1beta6 > Reporter: Mathias Bogaert > Priority: Minor > Fix For: 3.3.1 > > Attachments: natural-id-v2.patch, natural-id.patch > > > HIbernate 3.0.5 introduced natural-id. Add this to Annotations, as a @NaturalId annotation. -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=c... ] Steve Ebersole updated HHH-1569: -------------------------------- Fix Version/s: 3.3 3.2.5 > Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases > ------------------------------------------------------------------------- > > Key: HHH-1569 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569 > Project: Hibernate3 > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases > Reporter: Tom Dunstan > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.5, 3.3 > > Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip, ImmutableNaturalId-hibernate3.2.2.patch > > > It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug. It added the following lines: > if ( loaded == null ) { > loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister ); > } > Further down, loaded is used thusly: > int prop = props[i]; > if ( !updateable[prop] ) { > if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) { > throw new HibernateException( > Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays. > I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable. > Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used. > (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2). -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Assigned: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=c... ] Steve Ebersole reassigned HHH-1569: ----------------------------------- Assignee: Steve Ebersole > Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases > ------------------------------------------------------------------------- > > Key: HHH-1569 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569 > Project: Hibernate3 > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases > Reporter: Tom Dunstan > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.5, 3.3 > > Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip, ImmutableNaturalId-hibernate3.2.2.patch > > > It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug. It added the following lines: > if ( loaded == null ) { > loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister ); > } > Further down, loaded is used thusly: > int prop = props[i]; > if ( !updateable[prop] ) { > if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) { > throw new HibernateException( > Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays. > I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable. > Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used. > (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2). -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HBX-440) hbm2java does not generate correct POJO property types for UserType columns

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-440?page=co... ] Max Rydahl Andersen commented on HBX-440: ----------------------------------------- I can't reproduce this so you will have to open a new issue with a testcase proving it. > hbm2java does not generate correct POJO property types for UserType columns > --------------------------------------------------------------------------- > > Key: HBX-440 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-440 > Project: Hibernate Tools > Issue Type: Bug > Components: hbm2java > Affects Versions: 3.1alpha5 > Environment: Pulled from CVS somewhere between 3.1a5 and 3.1b1 > Reporter: James Schopp > Fix For: 3.1beta2 > > > I have defined my own custom UserType (which coincidentally maps a DB2 decimal field to a java.sql.Date property, using some special formatting...). > My mapping file contains: > <property name="connectDate" type="DecimalDateType"> > <column name="UMPCN" precision="8" scale="0" not-null="true" /> > </property> > where DecimalDateType is the fully-qualified name of my UserType class. > The POJO generated contains the property: > private DecimalDateType connectDate; > This is incorrect. It SHOULD have generated a property of the type returned by DecimalDateType.returnedClass() (which in this case is java.sql.Date.class). ie. It should have been > private java.sql.Date connectDate; > The "decision" of which type to generate (ie where the error manifests itself) error appears to be in > Cfg2JavaTool.java > in the method > private String getJavaTypeName(Value value, boolean preferRawTypeNames) > I am not sure of the exact fix, since there appear to be other checks being done, and I do not understand all the logic here. > Thanks! > james -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HBX-440) hbm2java does not generate correct POJO property types for UserType columns

by Brill Pappin (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-440?page=co... ] Brill Pappin commented on HBX-440: ---------------------------------- This doesn't appear to be fixed, I still have the issue. Whats stragne is that generation was working last time I ran it, I added a new UserType and not all pojo members of a particular type are set as the hibernate type not the class they should be. I'm using hibernate-3.2.1-ga > hbm2java does not generate correct POJO property types for UserType columns > --------------------------------------------------------------------------- > > Key: HBX-440 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-440 > Project: Hibernate Tools > Issue Type: Bug > Components: hbm2java > Affects Versions: 3.1alpha5 > Environment: Pulled from CVS somewhere between 3.1a5 and 3.1b1 > Reporter: James Schopp > Fix For: 3.1beta2 > > > I have defined my own custom UserType (which coincidentally maps a DB2 decimal field to a java.sql.Date property, using some special formatting...). > My mapping file contains: > <property name="connectDate" type="DecimalDateType"> > <column name="UMPCN" precision="8" scale="0" not-null="true" /> > </property> > where DecimalDateType is the fully-qualified name of my UserType class. > The POJO generated contains the property: > private DecimalDateType connectDate; > This is incorrect. It SHOULD have generated a property of the type returned by DecimalDateType.returnedClass() (which in this case is java.sql.Date.class). ie. It should have been > private java.sql.Date connectDate; > The "decision" of which type to generate (ie where the error manifests itself) error appears to be in > Cfg2JavaTool.java > in the method > private String getJavaTypeName(Value value, boolean preferRawTypeNames) > I am not sure of the exact fix, since there appear to be other checks being done, and I do not understand all the logic here. > Thanks! > james -- 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

17 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-487) IndexSearcher caching

by Emmanuel Bernard (JIRA)

IndexSearcher caching --------------------- Key: ANN-487 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-487 Project: Hibernate Annotations Type: New Feature Components: lucene Reporter: Emmanuel Bernard Fix For: 3.3.0 There is a way to cache IndexSearchers and still protect the user from read uncommited. IndexReader.isCurrent() -- 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

17 years, 7 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-62) Support pluggable ReaderProvider strategies

by Emmanuel Bernard (JIRA)

Support pluggable ReaderProvider strategies ------------------------------------------- Key: HSEARCH-62 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-62 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.0.0.beta2 -- 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

17 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-61) Move from MultiSearcher to MultiReader

by Emmanuel Bernard (JIRA)

Move from MultiSearcher to MultiReader -------------------------------------- Key: HSEARCH-61 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-61 Project: Hibernate Search Issue Type: New Feature Components: query Affects Versions: 3.0.0.beta2 Reporter: Emmanuel Bernard Lucene is more performant that way, and it helps to cache between queries -- 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

17 years, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-63) rename query.resultSize() to getResultSize()

by Emmanuel Bernard (JIRA)

rename query.resultSize() to getResultSize() -------------------------------------------- Key: HSEARCH-63 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-63 Project: Hibernate Search Issue Type: Improvement Components: query Affects Versions: 3.0.0.beta1 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.beta2 -- 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

17 years, 7 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2007