November 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2127) Document <filter-def condition="defaultCondition"> and <filter-def>defaultCondition

by Emmanuel Bernard (JIRA)

Document <filter-def condition="defaultCondition"> and <filter-def>defaultCondition ----------------------------------------------------------------------------------- Key: HHH-2127 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2127 Project: Hibernate3 Type: Improvement Components: documentation Reporter: Emmanuel Bernard Fix For: 3.2.1 -- 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

18 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Closed: (HHH-2208) Table schema use in DatabaseMetadata

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208?page=all ] Max Rydahl Andersen closed HHH-2208: ------------------------------------ Fix Version: 3.2.1 Resolution: Fixed fixed - schemaupdate/validate should now be better at handling multiple schemas > Table schema use in DatabaseMetadata > ------------------------------------ > > Key: HHH-2208 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.2.0.ga > Environment: Hibernate 2.1 beta 4, Oracle 8i > Reporter: Adrien > Fix For: 3.2.1 > Attachments: DatabaseMetadata.java, HB-534_patch.txt, TableMetadata.java, patch.txt, patch1.1.txt, patch1.2.txt, schemavalidation.zip > > > When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas. > The correct behavior would be to first look in the schema with the login name and after in any schema. > user1.article > user2.article > I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article. > Adrien -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Moved: (HHH-2208) Table schema use in DatabaseMetadata

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208?page=all ] Max Rydahl Andersen moved HB-534 to HHH-2208: --------------------------------------------- Project: Hibernate3 (was: Hibernate2) Key: HHH-2208 (was: HB-534) Issue Type: Improvement (was: Bug) Component: core (was: core) Version: 3.2.0.ga (was: 2.1 beta 4) > Table schema use in DatabaseMetadata > ------------------------------------ > > Key: HHH-2208 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.2.0.ga > Environment: Hibernate 2.1 beta 4, Oracle 8i > Reporter: Adrien > Attachments: DatabaseMetadata.java, HB-534_patch.txt, TableMetadata.java, patch.txt, patch1.1.txt, patch1.2.txt, schemavalidation.zip > > > When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas. > The correct behavior would be to first look in the schema with the login name and after in any schema. > user1.article > user2.article > I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article. > Adrien -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HBX-805) Split property summaries into id, version and simple property sections

by Mark Hobson (JIRA)

Split property summaries into id, version and simple property sections ---------------------------------------------------------------------- Key: HBX-805 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-805 Project: Hibernate Tools Type: Improvement Components: hbm2doc Versions: 3.2beta8 Reporter: Mark Hobson Attachments: patch.txt Attached patch: - moves id and version properties into their own summary and detail blocks - removes id and version properties from (simple) property block - moves inherited id and inherited version properties into their respective blocks -- 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

18 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HBX-806) Improve usability of table pages

by Mark Hobson (JIRA)

Improve usability of table pages -------------------------------- Key: HBX-806 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-806 Project: Hibernate Tools Type: Improvement Components: hbm2doc Versions: 3.2beta8 Reporter: Mark Hobson Attachments: patch.txt Attached patch: - reduces table summary page to list of schemas - reduces schema summary page to list of tables (leaving table summary to deliver the finer details) - adds missing tables-per-schema page -- 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

18 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1629) SchemaUpdate doesn't work with Postgres

by Nicklas Nordborg (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1629?page=c... ] Nicklas Nordborg commented on HHH-1629: --------------------------------------- We have published a modified version of hibernate3.jar which solves this issue. It can be downloaded from: http://base.thep.lu.se/wiki/UpgradePostgres Note that the jar is based on Hibernate 3.2.cr1 and should only be used if you have issues with the SchemaUpdate utility. Don't use it for running your application. > SchemaUpdate doesn't work with Postgres > --------------------------------------- > > Key: HHH-1629 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1629 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Environment: Hibernate 3.1.2 > Postgres 8.0.4 > Linux > Reporter: Nicklas Nordborg > Priority: Trivial > Attachments: AffyFeatureData.hbm.xml, patch-HHH-1629.txt > > > The SchemaUpdate only generates SQL with CREATE TABLE statements and can't update existing tables. > With debugging turned on the SchemaUpdate reports: > 11:25:22,599 INFO SchemaUpdate:114 - Running hbm2ddl schema update > 11:25:22,599 INFO SchemaUpdate:126 - fetching database metadata > .11:25:22,771 INFO SchemaUpdate:142 - updating schema > 11:25:22,803 INFO DatabaseMetadata:91 - table not found: AffyFeatures > 11:25:22,830 INFO DatabaseMetadata:91 - table not found: AnnotationSets > 11:25:22,855 INFO DatabaseMetadata:91 - table not found: AnnotationTypeItems > .... and so on for another 100+ tables > All tables except two exists in the database. The two new tables are created successfully by SchemaUpdate. > I attach one of my mapping files (generated by XDoclet). > I had a quick look at the SchemaUpdate code (which calls DatabaseMetadata) and I think the problem is that it converts the table names to upper or lower case, even though I have quoted them in the mapping files. If the DatabaseMetadata.getTableMetadata could take a Table object as a parameter instead of the name, schema and catalog, it could check the Table.isQuoted() method before converting any names to upper or lower case. It seems like this method is only used by the Configuration class so it shouldn't be too hard to fix. > I could do the fix myself, but I will only be able to validate it against Postgres and MySQL using quoted table names. So, others would probably have to validate it agains other databases and using unquoted table names. -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements

by Emmanuel Bernard (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ] Emmanuel Bernard commented on HHH-1258: --------------------------------------- It is worth a try sometime: use a multi threaded (2 to 4) approach for the CPU consuming areas. While not making a difference on regular CPU, it might start to increase performance on multi-core CPUs (This is really R&D since the regular John Doe developer ins not going to have multi core anytime soon). > startup time improvements > ------------------------- > > Key: HHH-1258 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.1 rc3 > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch > > > while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it: > Initial tests where 100 classes, 30 sec for buildSessionFactory > setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory. > (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact) > Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property. > (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors) > Other 20% of the time is done in net.sf.cglib related classes for build time enhancement. > The rest of the time is Configuration creation (can be cached) and other iteration code. > (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests > is done on pojos with a "high" method count (approx 100) -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1092) Remove finalize() from the org.hibernate.jdbc.ConnectionManager class

by Emmanuel Bernard (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1092?page=all ] Emmanuel Bernard resolved HHH-1092: ----------------------------------- Resolution: Fixed Was fixed as part of HHH-1240 > Remove finalize() from the org.hibernate.jdbc.ConnectionManager class > --------------------------------------------------------------------- > > Key: HHH-1092 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1092 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.1 rc2 > Environment: HIbernate 3.0.5, Database is not related to problem, but Solid Embedded Database with a custom dialect. (www.solidtech.com) > Reporter: John Adams > > Original Estimate: 1 day > Remaining: 1 day > > I just posted this to the user forums, and the immediate reply I got was to post this issue here. I have cut and paste my original posting here to save myself a bit of work.. The estimate is a bit of a strange one for me .... removing the finalize is trivial. Making sure hibernate is still safe and logs errors appropriately when connections don't get closed I imagine is not. If it is trivial, it would be nice if this change could make it into Hibernate 3.1, it would really help real time performance issues. > I marked it as major since this results in pausing of our JVM for periods of longer than 1 second, which means that we will have to address this issue. (our server is time sensitive). From our perspective this would be a major performance improvement, but I don't know exactly how to differentiate major & minor improvements in the program. > /snippet of original issue. > We have been using Hibernate successfully but with one problem, we have long gc pauses using the 1.5 concurrent collector. We previously had really long pauses with Hibernate 2.1.7, and had traced it down to the SessionImpl overriding finalize(). We looked at the 3.0.5 source and realized that SessionImpl had removed the finalize() modifier, which was great, so we upgraded. (I had read Gavin's blog on the topic) > However, we had missed two important details ... > 1) org.hibernate.jdbc.ConnectionManager also overrides finalize() > 2) Our JDBC driver vendor overrides finalize() in their statements > Now in our scenario, there is a 1:1 mapping between SessionImpl and ConnectionManager for various reasons, which kind of negates the advantage of taking finalize out of SessionImpl. We can help this situation out by using our Sessions for multiple database updates ... we're in the process of getting better about this. We also may be able to influence our database vendor to take the finalize() out of their driver, we need both to really fix our pausing with Sun's VM. > However, it remains that the ConnectionManager overrides finalize(), even in 3.1 rc2. Is there any way that the override can be taken out ? Any other suggestions besides being more frugal with our SessionImpl's ? > Regards, > John. > Hibernate version:3.05 > DatabaseVendor: Solid Embedded Database (http://www.solidtech.com/) > Java Version: 1.5.0_04 (Sun) > O/S: Linux Redhat 2.6.9 > ps. This shows up in the concurrent collector in long pauses as WeakReference processing if you want to see the effect. Finalizers create weak references, which is the bit the garbage collector complains about. -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1574) AbstractEntityPersister.getNaturalIdentifierSnapshot doesn't work with many-to-one ids

by Alex Burgel (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574?page=all ] Alex Burgel updated HHH-1574: ----------------------------- Attachment: resolveentity32.patch a newer version of the patch for 3.2, with the test cases included in the patch. this is based on tags/v32final/Hibernate3 > AbstractEntityPersister.getNaturalIdentifierSnapshot doesn't work with many-to-one ids > -------------------------------------------------------------------------------------- > > Key: HHH-1574 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574 > Project: Hibernate3 > Type: Bug > Versions: 3.1.2 > Reporter: Alex Burgel > Attachments: resolveentity.patch, resolveentity32.patch, testcase.zip > > > i just upgraded from 3.0.5 to 3.1.2, and i started seeing this problem. i'm not exactly sure where the bug is here, but this is what i'm seeing: > i have a class, Subscription, which has a natural-id of class Subscriber and Edition (excerpts of relevant mapping files below). > when Subscription is unloaded, if i make a change, then commit the session, i see this exception: > HibernateException: immutable natural identifier of an instance of Subscription was altered > this gets thrown from DefaultFlushEntityEventListener.checkNaturalId() line 80. > i traced through that method, this is what happens: > 1. in checkNaturalId, loaded == null , so getNaturalIdSnapshot() is called > 2. this ends up generating some sql that selects the SubscriptionId and EditionId from the Subscription row. > 3. the sql is generated in AbstractEntityPersister.getNaturalIdentifierSnapshot(), which calls hydrate for each returned column of the natural-id, > 4. but hydrate only returns the id, instead of the actual entity > 5. so this array of ids (instead of entities) ends up back in DefaultFlushEntityEventListener.checkNaturalId() as 'loaded', which gets compared to 'current' > the trouble is that 'current' contains the entities, but 'loaded' only contains the ids of those entites, so the natural-id check fails, and i get the exception. > this only happens when 'loaded' is null in checkNaturalId(). > the javadocs for hydrate say you have to call "resolve" afterwards... this isn't being done, so maybe thats the fix. if the natural-id is not just simple properties, then resolve should also be called. > <class name="Subscription" table="Subscriptions" batch-size="10"> > <id name="id" column="Id" type="int"><generator class="native" /></id> > <natural-id> > <many-to-one name="subscriber" class="Subscriber" column="SubscriberId" /> > <many-to-one name="edition" class="Edition" column="EditionId" /> > </natural-id> > .... > </class> > <class name="Subscriber" table="Subscriber"> > <id name="id" column="id" type="int"><generator class="native" /></id> > <map name="subscriptions" inverse="true" cascade="all,delete-orphan" batch-size="10"> > <key column="SubscriberId" /> > <map-key-many-to-many column="EditionId" class="Edition" /> > <one-to-many class="Subscription" /> > </map> > </class> -- 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

18 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1767) read-only cache for immutable collection causes unnecessary warning

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1767?page=all ] Steve Ebersole resolved HHH-1767: --------------------------------- Resolution: Fixed applied to trunk and 3.2 thanks! > read-only cache for immutable collection causes unnecessary warning > ------------------------------------------------------------------- > > Key: HHH-1767 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1767 > Project: Hibernate3 > Type: Patch > Components: core > Versions: 3.1.3 > Reporter: Alex Burgel > Assignee: Steve Ebersole > Priority: Trivial > Fix For: 3.2.1 > Attachments: SessionFactoryImpl.patch > > > SessionFactoryImpl always says collections are mutable when calling the CacheFactory, even if the mapping file says otherwise. this causes a warning in the CacheFactory -- 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

18 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2006