[Hibernate-JIRA] Created: (HHH-5261) Miscellaneous typos and a handful of minor content issues
by David M. Karr (JIRA)
Miscellaneous typos and a handful of minor content issues
---------------------------------------------------------
Key: HHH-5261
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5261
Project: Hibernate Core
Issue Type: Bug
Components: documentation
Affects Versions: 3.5.2
Reporter: David M. Karr
Priority: Minor
This is a collection of typos and minor content issues found in the current Hibernate doc. Technically, this represents multiple issues, but I'm not going to file one ticket for every typo I found.
Section 1.1.4, p. 7, first "Note": Change "... this do that ..." to "... this so that ...".
Section 1.2.4, p. 19, last paragraph. This paragraph has the first mention of "eager fetch" in the manual, but without any explanation. In a tutorial, it's confusing to mention technical terms without any background, and even worse when a technical term doesn't even sound like a technical term.
Section 1.3.1, p. 20, change "... need create ..." to "... need to create ...".
Section 1.3.1, p. 21, first code sample. Using "ServletException.class.isInstance(ex)" here seems odd. Why don't you use the more common "ex instanceof ServletException"? The dynamic form is only useful when the class is in a variable.
Section 1.3.1, p. 21, paragraph beginning "The pattern applied here ...". The last sentence in this paragraph seems strange here. It refers to not using "auto-commit", which is at least related to the subject of the paragraph, being "session-per-request", but it seems like it was placed in this paragraph accidentally.
Section 4.1.1, p. 52. This paragraph repeats a common misstatement I see in much of the Java literature. The statement "All persistent classes must have a default constructor" is incorrect. It should be "All persistent classes must have a no-arguments constructor". The "default constructor" is the constructor that the compiler creates in a class if no constructor is defined. The default constructor is a no-arguments constructor, but the point is that persistent classes need a no-arguments constructor, not a "default constructor".
Section 5.1.3, p. 65, definition of "batch-size". This explanation is confusing. It says "... for fetching instances of this class by identifier." Fetching instances of a class by an identifier value will only ever get one (or zero) rows.
Section 5.1.3, p. 65, definition of "rowid". Is this explanation correct? It says "... once this option has been set to rowid.". You enable the "rowid" property by setting it to "rowid"? If that's true, it would be helpful to emphasize that. Most people would read that and be confused.
Section 5.1.4.5, p. 71. Change "The generator is used ..." to "This generator is used ...".
Section 5.1.5, p. 71, paragraph beginning "The first of these new ...". Change "portability generator" to, perhaps, "identity generator". "portability generator", what a concept. :)
Section 5.1.13, p. 82, "constrained" definition. Change "... table and references ..." to "... table references ...".
Section 11.1, p. 164, change "... already in the in the session ..." to "... already in the session ...".
Section 11.1.1, p. 164. Change "... class can created ..." to "... class can be created ...".
Chapter 12, p. 173, second paragraph. The paragraph ends with "... Hibernate provides repeatable reads for lookup by identifier and entity queries and not reporting queries that return scalar values." The "not reporting" part doesn't seem to make sense. I can't tell what this was supposed to say.
Section 12.4, p. 185, change "... it never lock objects ..." to "... it never locks objects ...".
Section 15.10, p. 209. The "simple" case and the "searched" case both refer to an abbreviated code excerpt, which I would assume should not be the same. They appear to be identical, so what exactly is this saying then?
Section 15.16, p. 218, code sample after "Properties of a JavaBean can be bound to named query parameters". The query expression begins "from foo Foo as foo ...". That seems wrong. I think it should be "from Foo as foo ...".
Section 15.18, p. 219, code sample after "It can also be useful to specify this in the select clause ...". This section is about the row value constructor syntax. This example doesn't appear to demonstrate a row value constructor. It just says "select p.name from Person p".
Section 16.4, p. 224. Change "... retreive the cats with mates who's name ..." to "... retrieve the cats with mates whose name ...".
Section 16.6, p. 225. Concerning the reference to "enableLike()", it would be useful to state exactly what this does, instead of just "use like for string comparisons". Logic tells me that it would do "like '%value%'", but it would be useful to confirm that.
Section 17.1.4.1, table 17.1, change "The id of an collection" to "The id of a collection". Similarly, on the next page in the same table, change "The element of an collection" to "The element of a collection".
Section 20.1.7, p. 258, change "... fetch profile wull be ..." to "... fetch profile will be ...".
Section 20.1.7, p. 259, change "... but they plan is ..." to "... but the plan is ...".
Section 20.4.1, p. 265, change "... For this reaso, ..." to "... For this reason, ...".
Section 20.5.4, p. 268. Change "... then add thee ..." to "...then add these ...".
Section 22.2, p. 280, change "... the link (the foreign key parent_id) from p to c ..." to "... the link (the foreign key parent_id) from c to p ...".
Chapter 25, p. 305, change "... but his approach ..." to "... but this approach ...".
p. 306, in 'explicitly disable eager fetching using lazy="false"', change it to "disable lazy" or "enable eager".
Section 26.4, change "targtetting" to "targeting" and change "entitiy" to "entity". In the second "Note" change "enhancedgenerators" to "enhanced generators".
Section 26.5, p. 311. Change "Hibernate, provides ..." to "Hibernate provides ...".
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-5241) One-to-many relationship to class with JOINED inheritance causes assertion failure in JoinedSubclassEntityPersister
by Stu White (JIRA)
One-to-many relationship to class with JOINED inheritance causes assertion failure in JoinedSubclassEntityPersister
-------------------------------------------------------------------------------------------------------------------
Key: HHH-5241
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5241
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.0-CR-1
Environment: Hibernate 3.5.0-CR1 (included with JBoss Application Server 6.0.0 M2)
SQL Server 2005
Reporter: Stu White
Attachments: testcase.zip
I've created a JPA mapping for a class that has a one-to-many relationship via a join table to other classes which are using a JOINED inheritance strategy, and I'm getting an odd error which makes me wonder whether I've come across a bug in Hibernate.
The particular error I'm getting is:
Exception in thread "main" 2010-05-20 10:00:04,783 - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: Table JpaTest.ParentOwnerJoinTable not found
at org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId(JoinedSubclassEntityPersister.java:497)
at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init>(JoinedSubclassEntityPersister.java:276)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:87)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:272)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1385)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:974)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:850)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:56)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at com.i2group.jpatest.JpaTestBase.createEntityManager(JpaTestBase.java:51)
at com.i2group.jpatest.JpaOwnershipInheritanceTest.writeEntity(JpaOwnershipInheritanceTest.java:28)
at com.i2group.jpatest.JpaOwnershipInheritanceTest.main(JpaOwnershipInheritanceTest.java:22)
I've attached a zip containing the classes, persistence XML, and SQL Server setup script. The classes are:
Owner The owner linked by a one-to-many relationship to Parent/ChildOne/ChildTwo
Parent Parent class using a JOINED inheritance strategy
ChildOne Child of Parent
ChildTwo Child of Parent
The error only seems to occur when combining a one-to-many relationship via a join table to a class using inheritance. If I remove the link to Owner and just test the inheritance of Parent/ChildOne/ChildTwo then it works fine. If I remove the inheritance and just test the one-to-many relationship from Owner to Parent then it works fine. If I try to combine the two then I get the error above.
I don't think I'm doing anything particularly obscure, which makes me suspicious that this is more likely to be a mistake in my configuration than a bug in Hibernate. However, I've checked the configuration and tested parts of it separately and have been unable to find what (if anything) I'm doing wrong.
If there's any further information I can provide to help diagnose this then please let me know.
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-2645) Synchronization bottleneck in EntityModeToTuplizerMapping
by Erik Bergersjö (JIRA)
Synchronization bottleneck in EntityModeToTuplizerMapping
---------------------------------------------------------
Key: HHH-2645
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2645
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.3 (and later), Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10, Oracle 10g R2
Reporter: Erik Bergersjö
Priority: Minor
We have had a major performance bottleneck in EntityModeToTuplizerMapping with Hibernate version 3.2.3 and the code for that class in 3.2.4sp1 is unchanged. We have found a solution that solves the issue and would like to get it into the real version. I submitted to the user forum first and was asked to create a JIRA issue.
The problematic line is:
private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() );
We have changed it to (using util.concurrent):
private final Map tuplizers = new EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap();
This change alone makes our use cases six times faster. The difference is that ConcurrentReaderHashMap handles concurrent readers much better, they don't have to wait for each other.
The problem occurs when a high number of threads try to initialize sets (see mapping below). A thread dump showed a high number of threads waiting for the same monitor, see partial stack trace below.
The code runs on Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10 and the kernel spends a lot of time handling mutexes with the original implementation. That time disappears from the radar screen with the fixed version.
Example mapping for set:
[code]
<set name="lines" lazy="true" inverse="true" cascade="all-delete-orphan">
<key>
<column name="col1" not-null="true" />
<column name="col2" not-null="true" />
</key>
<one-to-many class="LineClass" />
</set>
[/code]
Stack trace (partial):
"Thread-108" prio=5 tid=0x05852e90 nid=0x103 waiting for monitor entry [0x3ed7e000..0x3ed7fc28]
at java.util.Collections$SynchronizedMap.get(Collections.java:1942)
- waiting to lock <0x89d30788> (a java.util.Collections$SynchronizedMap)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizerOrNull(EntityModeToTuplizerMapping.java:53)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizer(EntityModeToTuplizerMapping.java:66)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353)
at org.hibernate.type.ComponentType.isEqual(ComponentType.java:141)
at org.hibernate.engine.CollectionKey.equals(CollectionKey.java:50)
at java.util.HashMap.eq(HashMap.java:274)
at java.util.HashMap.get(HashMap.java:323)
at org.hibernate.engine.loading.CollectionLoadContext.getLocalLoadingCollectionEntry(CollectionLoadContext.java:163)
at org.hibernate.engine.loading.CollectionLoadContext.locateLoadingCollectionEntry(CollectionLoadContext.java:150)
at org.hibernate.engine.loading.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:92)
at org.hibernate.loader.Loader.readCollectionElement(Loader.java:1003)
at org.hibernate.loader.Loader.readCollectionElements(Loader.java:646)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:591)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1994)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentSet.iterator(PersistentSet.java:163)
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-5250) On setting a String-Value for a integer entity-field in a criterion, produces a ClassCastException, see also HHH-5238
by Hannes Havel (JIRA)
On setting a String-Value for a integer entity-field in a criterion, produces a ClassCastException, see also HHH-5238
---------------------------------------------------------------------------------------------------------------------
Key: HHH-5250
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5250
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.1
Reporter: Hannes Havel
SEE HHH-5238
Hi Gail,
I am not agree you, that this is not a BUG.
I am not amused that you switch the issue HHH-5238 to resolved, with out any explanation of your view.
Second: your reference, that i should use the forum for help is not on the right place.
because i know, what a question is and what a bug report is.
(I have 20 year of experiance in software development).
================================================
Explanation of my view:
In this case the string consists only numbers and representing a integer number of e.g. "10" and this can be converted to a integer 10 and i am not speaking about to convert a text string to an integer.
JDBC an do this easily.
Is hibernate so restricted ?
How you can establish a generalized query interface where only strings are transported and the provided service has no knowledge about the queried entities and the datatypes of the fields.
So i think a automatic conversion of a string representing a number to the nhumber type and so on is a esential funktionality for a
data sorage and retrieve interface.
For Hibernate the only thing to be changed for the primitive datatype handling is explaind in the following code snipplet:
IntegerType.set(PreparedStatement st, Object value, int index)
throws SQLException {
if (value instanceof String)
st.setInt( index, Integer.parseInt((String)value));
else
st.setInt( index, ( (Integer) value ).intValue() );
}
--
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
14 years, 7 months
[Hibernate-JIRA] Created: (HHH-5249) Component.java MappingException needs more detail
by Travis Stevens (JIRA)
Component.java MappingException needs more detail
-------------------------------------------------
Key: HHH-5249
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5249
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.5.2, 3.5.0-Final
Environment: Hibernate version: 3.5.0-Final
Reporter: Travis Stevens
Priority: Trivial
Attachments: mrxtravis-component.patch
A MappingException is thrown in the Component.java class that looks like such:
throw new MappingException("component property not found: " + propertyName);
I received this message when the property was 'id' -- and since every component has an 'id', this was not a very useful message. I'm supplying a patch that will add the componentClassName property of Component to the exception as to put the property in a useful context. The fix is :
throw new MappingException("component " + componentClassName + " property not found: " + propertyName);
See attachment for the patch to 3.5.0-Final
--
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
14 years, 7 months