[Hibernate-JIRA] Created: (ANN-606) Annotation Validation: @Immutable annotation does not throw error or warning on usage on subclass
by Paul Singleton Kossler (JIRA)
Annotation Validation: @Immutable annotation does not throw error or warning on usage on subclass
--------------------------------------------------------------------------------------------------
Key: ANN-606
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-606
Project: Hibernate Annotations
Issue Type: Bug
Components: binder, documentation
Affects Versions: 3.3.0.ga
Environment: Hibernate3, Annotations.3.3.0
Reporter: Paul Singleton Kossler
The @Immutable annotation does not throw a configuration error when used on a subclass. The action required depends upon the decision in a bug/patch request for adding mutable=false to subclasses. In the current rule set the Mapping Schema for pre annotations is leveraged to define the legallity of declaring a mapped object Immutable. Base/Root classes allowed, child classes of Mutable=true not allowed, in either case the mutability of an object is directly dependent upon the mutability of the root mapped object in the object hierarchy.
The following documentation sources do not mention the issue in relation to the @Immutable annotation:
* online/down-loadable Hibernate-Annotations
* Java Persistence with Hibernate (ISBN: 1-932394-88-5)
If the rules outlined above are accurate or not: A validation error or warning should be thrown from Configuration during the loading of an incorrectly mapped class. The current method is to check the Annotations at bind time, and only at the "correct" location. This meta-rule validation should occur during the binding of a mapping to the Configuration, quickly indicating an error. Using the "older" xml based mapping this occurs when the schema (xsd) validates the mapping file (xml).
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-1830) Error during parse query on MS SQL
by Tim McCune (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1830?page=c... ]
Tim McCune commented on HHH-1830:
---------------------------------
This one is killing us. Its status is still "awaiting test case". It's been 2 months since the first test case was submitted, and over 1month since the second. Could someone please change its status (and ideally fix it?) :)
Thanks.
> Error during parse query on MS SQL
> ----------------------------------
>
> Key: HHH-1830
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1830
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.1.2, 3.2.0.cr2
> Environment: Microsoft SQL Server 2000, Windows XP, JDK 1.5 Update 4
> Reporter: Den Raskovalov
> Priority: Critical
> Attachments: hibernateBug.tar.gz, hibernateBug.zip
>
>
> HQL: select deal, items.dateBegin, client.Title from " + CoreDeal.class.getName() + " deal left join deal.stagesWorkflowInstance.history.items items, " + CoreClient.class.getName() + " client where stageResponsible=:stageResponsible and items.index=maxindex(items) and deal.parent=client and deal.stagesWorkflowInstance.Stage.showOnPersonalPage=1
> It works normally on Oracle, but on MS SQL produces:
> Error: String index out of range: -5
> [java.lang.StringIndexOutOfBoundsException]
> java.lang.String.substring(String.java:1768)
> java.lang.String.substring(String.java:1735)
> org.hibernate.hql.CollectionSubqueryFactory.createCollectionSubquery(CollectionSubqueryFactory.java:32)
> org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:301)
> org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:291)
> org.hibernate.hql.ast.tree.FromElement.toColumns(FromElement.java:377)
> org.hibernate.hql.ast.tree.MethodNode.resolveCollectionProperty(MethodNode.java:115)
> org.hibernate.hql.ast.tree.MethodNode.collectionProperty(MethodNode.java:95)
> org.hibernate.hql.ast.tree.MethodNode.resolve(MethodNode.java:44)
> org.hibernate.hql.ast.HqlSqlWalker.processFunction(HqlSqlWalker.java:844)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.functionCall(HqlSqlBaseWalker.java:2324)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1285)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3521)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1686)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:577)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
> org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
> org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:227)
> org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:159)
> org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110)
> org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:77)
> org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:56)
> org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
> org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
> org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1612)
> ru.naumen.crm2.bobjects.deal.CoreDealHibernateHandler.listAllDealsWithSortDataByResponsible(CoreDealHibernateHandler.java:109)
> ru.naumen.crm2.ui.tlc.CoreEmployeeTableListController.listMyDealsSorted(CoreEmployeeTableListController.java:70)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
--
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
16 years
[Hibernate-JIRA] Created: (EJB-350) EJB3 delete problem with detached entities
by Balwinder Sodhi (JIRA)
EJB3 delete problem with detached entities
------------------------------------------
Key: EJB-350
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-350
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.3.1.GA
Environment: hibernate-3.2.5.ga, hibernate-entitymanager-3.3.1.GA, MS SQL Server, Windows XP Profesisonal
Reporter: Balwinder Sodhi
Trying to remove a detached entity fails with the exception given below. Looking into the source code at EJB3DeleteEventListener.java:45 I find that the method (pasted below) *always* throws the exception at line#45 regardless of the event contents.
@Override
protected void performDetachedEntityDeletionCheck(DeleteEvent event) {
EventSource source = event.getSession();
String entityName = event.getEntityName();
EntityPersister persister = source.getEntityPersister( entityName, event.getObject() );
Serializable id = persister.getIdentifier( event.getObject(), source.getEntityMode() );
entityName = entityName == null ? source.guessEntityName( event.getObject() ) : entityName;
throw new IllegalArgumentException("Removing a detached instance "+ entityName + "#" + id);
}
java.lang.IllegalArgumentException: Removing a detached instance com.xxx.em.Edition#282
at org.hibernate.ejb.event.EJB3DeleteEventListener.performDetachedEntityDeletionCheck(EJB3DeleteEventListener.java:45)
at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:86)
at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:52)
at org.hibernate.impl.SessionImpl.fireDelete(SessionImpl.java:766)
at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:744)
at org.hibernate.ejb.AbstractEntityManagerImpl.remove(AbstractEntityManagerImpl.java:246)
--
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
16 years
[Hibernate-JIRA] Created: (EJB-347) Merge does a useless refresh of a non-cascaded OneToMany List before de-initializing that List (testcase PATCH)
by Geoffrey De Smet (JIRA)
Merge does a useless refresh of a non-cascaded OneToMany List before de-initializing that List (testcase PATCH)
---------------------------------------------------------------------------------------------------------------
Key: EJB-347
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-347
Project: Hibernate Entity Manager
Issue Type: Improvement
Components: EntityManager
Affects Versions: 3.3.2.GA
Reporter: Geoffrey De Smet
Testcase patch attached.
When merging a detached Author which had it's songs fetched (but there is no cascading to those songs),
hibernate first does a useless check if all those songs still exist (but doesn't check their optimistic lock),
and then returns the Author with a not intialized songs list.
That check is very inconsistent:
- if a song has been updated, it works, except that it shows an n +1 query problem (wihen not using BatchSize)
- if a song has been deleted, it crashes, even though the merge isn't cascaded. It doesn't give an OptmisticLockingException, but this exception:
javax.persistence.EntityNotFoundException: Unable to find org.hibernate.ejb.test.cascade.Song with id 51
If this behaviour is mandated by the JPA spec, an annotation, much like @OptimisticLock(excluded = true), to turn off this unwanted behaviour, would be wonderfull :)
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3219) HQL query with IN using inner query generates invalid SQL for MySQL
by Luís Fernando Arcaro (JIRA)
HQL query with IN using inner query generates invalid SQL for MySQL
-------------------------------------------------------------------
Key: HHH-3219
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3219
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: Hibernate 3.2.5GA, Hibernate 3.2.6GA, MySQL 5.0.18
Reporter: Luís Fernando Arcaro
For MySQL, the following HQL query:
SELECT cnFont.cdFont AS cdFont,
cnFont.nmFont AS nmFont,
(
CASE WHEN cnFont IN (
SELECT cnPanel.cnPanelFont
FROM CnPanel cnPanel
WHERE cnPanel.cdPanel = :cdPanel
) THEN 1 ELSE 0 END
) AS fgAssociated
FROM CnFont cnFont
Generates the (invalid) following SQL:
select cnfont0_.cdFont as col_0_0_, cnfont0_.nmFont as col_1_0_, case when cnfont0_.cdFont in (select . from cnPanel cnpanel1_, cnPanelFont cnpanelfon2_, cnFont cnfont3_ where cnpanel1_.cdPanel=cnpanelfon2_.cdPanel and cnpanelfon2_.cdFont=cnfont3_.cdFont and cnpanel1_.cdPanel=?) then 1 else 0 end as col_2_0_ from cnFont cnfont0_
See "...select . from.." in the inner query: should be "...select cnfont3_.cdFont from..."?
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3179) Incorrect SQL using formula in component or as key with optimistic-lock="dirty"
by Heinz Huber (JIRA)
Incorrect SQL using formula in component or as key with optimistic-lock="dirty"
-------------------------------------------------------------------------------
Key: HHH-3179
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3179
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6ga
Oracle 10i (should not matter)
Reporter: Heinz Huber
Attachments: association-formula.zip
Don't generate null as column name for formulas on dirty optimisic locking.
Effect: If a component (or an association) used for the generation of the where clause for optimistic locking by dirty properties contained a formula, null would have been inserted as column name. Now these values are skipped.
Example:
<class name="Verfueger" table="ELVFGR" dynamic-insert="true" dynamic-update="true" select-before-update="true" optimistic-lock="dirty"
rowid="rowid">
<composite-id name="nummer">
<key-many-to-one name="mandant" column="vfMand" />
<key-property name="anlagekennzeichen" column="vfAkzV" />
<key-property name="nummer" column="vfVfNr" length="6" />
</composite-id>
<many-to-one name="kunde" cascade="evict" fetch="select" not-null="true" lazy="false" not-found="keep">
<formula>vfMand</formula>
<column name="vfAkzD" />
<column name="vfKdNr" />
</many-to-one>
</class>
If property kunde was changed and the entity is being updated, the where clause would have been:
vfMand = ? and vfAkzV = ? and vfVfNr = ? and null = ? and vfAkzD = ? and vfKdNr = ?
Clearly, the null is wrong!
Extent:
src/org/hibernate/persister/entity/AbstractEntityPersister.java
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3181) Legacy databases: Advanced handling of missing foreign key values
by Heinz Huber (JIRA)
Legacy databases: Advanced handling of missing foreign key values
-----------------------------------------------------------------
Key: HHH-3181
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3181
Project: Hibernate3
Issue Type: New Feature
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6
Oracle 10i (irrelevant)
Reporter: Heinz Huber
Attachments: not-found-keep.zip
"keep" as valid value for attribute not-found of many-to-one/many.
Effect: If the referenced object can't be found, a dummy object with the given key is constructed.
Example: Account.currency contains the value XYZ. This currency can't be found in the corresponding code table. After loading the account contains a currency object XYZ nontheless.
Extent:
src/org/hibernate/hibernate-mapping-3.0.dtd
src/org/hibernate/cfg/HbmBinder.java
src/org/hibernate/engine/ForeignKeys.java
src/org/hibernate/mapping/ManyToOne.java
src/org/hibernate/mapping/OneToMany.java
src/org/hibernate/type/EntityType.java
src/org/hibernate/type/ManyToOneType.java
src/org/hibernate/type/OneToOneType.java
src/org/hibernate/type/TypeFactory.java
There are some TODOs left:
- The handling of proxies should be improved.
- Currently works only per target entity (see comment in test).
But it works for
--
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
16 years
[Hibernate-JIRA] Updated: (HHH-1574) AbstractEntityPersister.getNaturalIdentifierSnapshot doesn't work with many-to-one ids
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574?page=c... ]
Max Rydahl Andersen updated HHH-1574:
-------------------------------------
Issue Type: Patch (was: Bug)
> 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
> Issue Type: Patch
> Affects 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
16 years
[Hibernate-JIRA] Created: (HHH-3189) Update c3p0 to 0.9.1.2
by Jean-Philippe Bouchard (JIRA)
Update c3p0 to 0.9.1.2
----------------------
Key: HHH-3189
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3189
Project: Hibernate3
Issue Type: Task
Components: core
Affects Versions: 3.2.5
Environment: Tomcat 5.5, Hibernate 3.2.5, MySQL 4.1.11a-4sarge, c3p0 0.9.1
Reporter: Jean-Philippe Bouchard
Priority: Minor
Attachments: borked.txt
I run a pretty busy site and every 24 hours or so, the system completely locks up and I have to restart tomcat. I investigated and the problem occurs in c3p0 which I use for my connection pooling. I attached a file containing the stack traces (obtained with JConsole) of some of the http processor threads when the system locks up. Using JConsole, I also tried to run softResetAllUsers() on the pooled datasource when the system is locked up and that fixes the issue as well.
In the change log for c3p0 0.9.1.2, they mention a fix of a deadlock issue so I tried the new version and the problem doesn't occur anymore.
--
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
16 years