[Hibernate-JIRA] Created: (HHH-2583) inconsistency in case sensitivity of dialect registered keywords
by Pete Cassin (JIRA)
inconsistency in case sensitivity of dialect registered keywords
----------------------------------------------------------------
Key: HHH-2583
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2583
Project: Hibernate3
Issue Type: Bug
Components: documentation, query-hql
Affects Versions: 3.2.3
Reporter: Pete Cassin
Priority: Minor
Right now, the Dialect.registerKeyword() method seems to add a given Keyword to the set as is, without taking the lower case. This would be fine if the intent was to allow case sensitive keywords, however it becomes problematic when these dialect specified keywords are used by the method Template.isFunctionOrKeyword() - the tokens passed to this method always have toLowerCase() called on them prior to being passed in.
Thus, if I create a keyword
"someKeyword"
It will never be recognized as such because even if I included it in my hql with identical case, that method will always be checking the dialect's keyword set for "somekeyword".
thus, HQL passed into Template.renderWhereStringTemplate will end up incorrectly qualifying the keyword with a table name.
This isn't a serious bug by any means, but it may be good to at least note in documentation that user-specified keywords have to be all lowercase in order to function properly.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2542) NullPointerException in TypeFactory.replaceAssociations for ComponentType
by Reto Urfer (JIRA)
NullPointerException in TypeFactory.replaceAssociations for ComponentType
-------------------------------------------------------------------------
Key: HHH-2542
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2542
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Reporter: Reto Urfer
The following code block will throw a NullPointerException when targetComponentValues should be determines and target[i] contains a NULL value.
else if ( types[i].isComponentType() ) {
// need to extract the component values and check for subtype replacements...
AbstractComponentType componentType = ( AbstractComponentType ) types[i];
Type[] subtypes = componentType.getSubtypes();
Object[] origComponentValues = original[i] == null ? new Object[subtypes.length] : componentType.getPropertyValues( original[i], session );
Object[] targetComponentValues = componentType.getPropertyValues( target[i], session );
replaceAssociations( origComponentValues, targetComponentValues, subtypes, session, null, copyCache, foreignKeyDirection );
This problem can be fixed the same way as it is prevented when origComponentValues are determined (see following line)
Object[] targetComponentValues = target[i] == null ? new Object[subtypes.length] : componentType.getPropertyValues( target[i], session );
copied[i] = target[i];
}
The problem did not exist in Version 3.2.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, 4 months
[Hibernate-JIRA] Created: (HHH-2369) Documentation doesn't state what hibernate returns for empty/null collections
by James Roper (JIRA)
Documentation doesn't state what hibernate returns for empty/null collections
-----------------------------------------------------------------------------
Key: HHH-2369
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2369
Project: Hibernate3
Type: Improvement
Components: documentation
Versions: 3.2.1
Reporter: James Roper
Priority: Trivial
Reading the hibernate documentation, section 6.1:
"Hibernate does not distinguish between a null collection reference and an empty collection"
This is all very well, but what does hibernate return when loading a null/empty collection?
According to the EJB3 specification, section 2.1.7:
"If there are no associated entities for a multi-valued relationship of an entity fetched from the database, the persistence provider is responsible for returning an empty collection as the value of the relationship."
If this is the behavior that hibernate implements, then this should be explicitly stated in the hibernate documentation, so that developers know whether they need to do null checks or not after loading an object from the database.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2468) Is setParameter 0- or 1-based?
by Rafael Borges (JIRA)
Is setParameter 0- or 1-based?
------------------------------
Key: HHH-2468
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2468
Project: Hibernate3
Type: Bug
Versions: 3.2.2
Environment: Hibernate 3.2.2.GA, RDBMS: H2, version: 1.0 (2007-01-30), JDK 6.0, Windows XP Pro
Reporter: Rafael Borges
Priority: Trivial
The following query throws a wrong message in the Exception
== Query ==
query = session.createQuery("select t from Test t where t.id = ?");
query.setParameter(1, 1);
== Message ==
Exception in thread "main" java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based!
at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterDescriptor(ParameterMetadata.java:55)
at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterExpectedType(ParameterMetadata.java:61)
at org.hibernate.impl.AbstractQueryImpl.determineType(AbstractQueryImpl.java:397)
at org.hibernate.impl.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:369)
at Test.main(Test.java:25)
The Javadoc says it is 0-based, and that works perfectly when used accordingly. So I think it is just a comestic fix.
--
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, 4 months
[Hibernate-JIRA] Created: (ANN-615) Inherited relationships not found in collections of subclasses of the entity containing the relationship
by Michael Newcomb (JIRA)
Inherited relationships not found in collections of subclasses of the entity containing the relationship
--------------------------------------------------------------------------------------------------------
Key: ANN-615
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-615
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Reporter: Michael Newcomb
Consider:
@Entity
public class A
{
@Id
@GeneratedValue
protected int id;
@OneToMany(mappedBy = "a")
protected Collection<C> c;
}
@Entity
public abstract class B
{
@Id
@GeneratedValue
protected int id;
@ManyToOne
protected A a;
}
@Entity
public class C
extends B
{
}
Gives the following errors upon deployment:
Caused by: org.hibernate.AnnotationException: mappedBy reference an unknown target entity property: com.gd.iewtpt.isi.C.a in com.gd.iewtpt.isi.A.c
at org.hibernate.cfg.annotations.CollectionBinder.bindStarToManySecondPass(CollectionBinder.java:552)
at org.hibernate.cfg.annotations.CollectionBinder$1.secondPass(CollectionBinder.java:517)
at org.hibernate.cfg.CollectionSecondPass.doSecondPass(CollectionSecondPass.java:43)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1130)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:316)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1269)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:150)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:888)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:186)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:246)
... 7 more
I can get around this issue, but it seems there is a bug here...
--
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, 4 months
[Hibernate-JIRA] Created: (HBX-915) CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
by Brill Pappin (JIRA)
CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
---------------------------------------------------------------------------------------------------------------
Key: HBX-915
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-915
Project: Hibernate Tools
Type: Bug
Components: ant
Versions: 3.1beta4
Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
Reporter: Brill Pappin
Fix For: 3.2beta7
I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error.
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
[snip]
Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
[snip]
I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
.. and it worked fine!
So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
I'd suggest a couple of possible fixes/improvements:
- Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
- Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.
--
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, 5 months