[Hibernate-JIRA] Created: (HV-409) Provide the possibility to specify parameter names for reporting method level constraint violations
by Gunnar Morling (JIRA)
Provide the possibility to specify parameter names for reporting method level constraint violations
---------------------------------------------------------------------------------------------------
Key: HV-409
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-409
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Gunnar Morling
When reporting a method level constraint violation besides the concerned method the parameter causing the violation is a substantial information. As the Java byte code usually doesn't contain any information on parameter names only the index of the parameter can be returned in the resulting MethodConstraintViolation.
In order to produce expressive constraint violations it is desirable to have the possibility to specify parameter names in some way. One approach for this might be to allow parameter names being specified with the help of an appropriate annotation. Using JSR 330's @Named annotation for instance this could look like this:
{code:java}
someMethod(@Named("param1") @NotNull String param1, @Named("customer") @NotNull @Valid Customer customer) {
//...
}
{code}
In case any of the method's constraints is violated the resulting MethodConstraintViolation would refer to this name in getName() and getPropertyPath():
{code:java}
assertEquals( constraintViolation.getParameterName(), "customer" );
assertEquals(
constraintViolation.getPropertyPath().toString(),
"SomeType#someMethod(customer).name"
);
{code}
This approach was prototyped in https://github.com/gunnarmorling/hibernate-validator/commits/method-level... but was removed for HV 4.2 with [e7e3c5f6e97d850b65579fc542599d4c9241048d|https://github.com/gunnarmorling...] and [8fbc2cca1481563309a03f58ccb4037134772801|https://github.com/gunnarmorling...] to have time for some more considerations.
In especially an algorithm for retrieving the effective name of a method parameter has to be defined. This might look like this:
* If the validated method doesn't override any method from a super type the parameter names are taken from this method (if given)
* If the validated method does override a method from a super type, the closest names found up in the inheritance tree are taken (e.g. when validating A#foo() overriding B#foo() in turn overriding C#foo() and both B and C provide parameter names for foo(), then the names from B#foo() are taken)
* If the name for a parameter is given in two or more equally distant types, the names of any from the closest types are taken, from which of this is not defined (e.g. when validating A#foo() implementing B#foo() and C#foo() and both B and C specify parameter names for foo(), the names either from B or C are taken)
When implementing this feature HV should not require new strict dependencies; so if for instance working with @Named, javax.inject-1.jar should be added in optional scope and the type javax.inject.Named should be accessed only using reflection.
--
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
11 years, 7 months
[Hibernate-JIRA] Created: (HHH-4700) ClassCastException with parameter in CaseNode.getFirstThenNode()
by Jean-Baptiste Mille (JIRA)
ClassCastException with parameter in CaseNode.getFirstThenNode()
----------------------------------------------------------------
Key: HHH-4700
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4700
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.3.2, 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.7, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1
Environment: Hibernate 3.3.2.ga
Reporter: Jean-Baptiste Mille
Priority: Minor
Attachments: testcase.zip
Hql query with CASE .. WHEN and parameter in THEN clause throws a classCastException.
Example :
{code}
UPDATE MyObject SET myProperty = CASE WHEN myFilterProperty like 'L%' THEN :new_value END
{code}
Exception
java.lang.ClassCastException: org.hibernate.hql.ast.tree.ParameterNode cannot be cast to org.hibernate.hql.ast.tree.SelectExpression
at org.hibernate.hql.ast.tree.CaseNode.getFirstThenNode(CaseNode.java:44)
at org.hibernate.hql.ast.tree.CaseNode.getDataType(CaseNode.java:40)
at org.hibernate.hql.ast.tree.BinaryLogicOperatorNode.extractDataType(BinaryLogicOperatorNode.java:210)
at org.hibernate.hql.ast.tree.BinaryLogicOperatorNode.initialize(BinaryLogicOperatorNode.java:58)
at org.hibernate.hql.ast.HqlSqlWalker.prepareLogicOperator(HqlSqlWalker.java:1133)
at org.hibernate.hql.ast.HqlSqlWalker.evaluateAssignment(HqlSqlWalker.java:1043)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.assignment(HqlSqlBaseWalker.java:1086)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.setClause(HqlSqlBaseWalker.java:766)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.updateStatement(HqlSqlBaseWalker.java:361)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:239)
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:254)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:185)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
at com.bnpparibas.eqd.DMLCaseTest.runQuery(DMLCaseTest.java:67)
at com.bnpparibas.eqd.DMLCaseTest.doesntWork(DMLCaseTest.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
This issue have been [posted in user forum|https://forum.hibernate.org/viewtopic.php?f=1&t=981196&p=2369061&hi...].
It works with Hibernate 3.1.3.
A test case (designed for Hibernate 3.3.2.ga) which illustrate this issue is attached.
--
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
11 years, 7 months
[Hibernate-JIRA] Created: (HHH-4947) Silent exclusion of null-valued map entry
by Tsering Shrestha (JIRA)
Silent exclusion of null-valued map entry
-----------------------------------------
Key: HHH-4947
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4947
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-CR-1, 3.3.2
Reporter: Tsering Shrestha
<class name="Product">
<id name="id">
<generator class="native"/>
</id>
<map name="sellingPrice">
<key column="PRODUCT" not-null="true" foreign-key="FK_SP_PRODUCT"/>
<map-key type="string" column="model" not-null="true"/>
<element type="double" column="price" not-null="false"/>
</map>
</class>
Product product = new Product();
Product.getSellingPrice().put("XL",null);
Product.getSellingPrice().put("L", 34.90);
session.save(product)
Gives the following SQL:
insert into PRODUCT (id) values (null)
call identity()
insert into SELLINGPRICE (PRODUCT, MODEL, PRICE) values (?, ?, ?)
And the SELLINGPRICE table indeed only has one row. Why does Hibernately *silently* remove my null-valued entry? I would either want it to be able to save the entry or raise an exception that it cannot.
Report this post
--
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
11 years, 7 months
[Hibernate-JIRA] Created: (HHH-2031) Add functions to Dialect that can disable use of schema and catalog parts -- for HSQLDB support
by Brian Holmes (JIRA)
Add functions to Dialect that can disable use of schema and catalog parts -- for HSQLDB support
-----------------------------------------------------------------------------------------------
Key: HHH-2031
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2031
Project: Hibernate3
Type: Patch
Components: core
Versions: 3.1.3
Environment: This patch is against r9668 of /tags/v313/Hibernate3.
Reporter: Brian Holmes
Attachments: hibernate3-v313-support_schema_catalog_names.patch
HSQLDB does not support the use of three part names, that is Tables with schema and catalog parts.
This patch adds two functions to Dialect: supportsSchemaNames() and supportsCatalogNames(). Table.getQualifiedName() checks these values to decide whether to use or ignore the schema and catalog parts.
By default these are enabled in Dialect. This patch only disables their use in HSQLDialect.
This change is necessary for people who normally use Schema and Catalog names for access their primary database, but also use HSQLDB for Unit Testing. Without it, HSQLDB is unusable for Unit Testing because it fails on use of any catalog or schema 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
11 years, 7 months