November 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-62) Rename ValidatorBuilder to ValidatorFactoryBuilder

by Emmanuel Bernard (JIRA)

Rename ValidatorBuilder to ValidatorFactoryBuilder -------------------------------------------------- Key: BVAL-62 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-62 Project: Bean Validation Issue Type: Improvement Components: ri-general, spec-general Reporter: Emmanuel Bernard Fix For: 1.0 public draft -- 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, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-64) Rename getValidatedProperties to getPropertiesWithConstraints()

by Emmanuel Bernard (JIRA)

Rename getValidatedProperties to getPropertiesWithConstraints() --------------------------------------------------------------- Key: BVAL-64 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-64 Project: Bean Validation Issue Type: Improvement Components: ri-general, spec-general Reporter: Emmanuel Bernard -- 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, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3587) HQL 'cast' function partially broken with MySQL

by Manuel Dominguez Sarmiento (JIRA)

HQL 'cast' function partially broken with MySQL ----------------------------------------------- Key: HHH-3587 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3587 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: MySQL 5 Reporter: Manuel Dominguez Sarmiento Priority: Trivial MySQLDialect .getCastTypeName() is not fully implemented. It breaks when trying to cast to LONG (BIGINT). This can be easily fixed: public String getCastTypeName(int code) { if ( code==Types.INTEGER || code == Types.BIGINT ) { return "signed"; } else if ( code==Types.VARCHAR ) { return "char"; } else if ( code==Types.VARBINARY ) { return "binary"; } else { return super.getCastTypeName( code ); } } -- 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, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (BVAL-3) Replace array return types with Sets

by Hardy Ferentschik (JIRA)

Replace array return types with Sets ------------------------------------ Key: BVAL-3 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-3 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Hardy Ferentschik the following methods in the Spec return arrays. They should return sets of the appropriate types: InvalidConstraint.getGroups() ConstraintDescriptor.getGroups() ElementDescriptor.getConstraintDescriptors() -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-4) Return value for @NotEmpty for null values

by Hardy Ferentschik (JIRA)

Return value for @NotEmpty for null values ------------------------------------------ Key: BVAL-4 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-4 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Hardy Ferentschik The spec says: "While not mandatory, it is considered a good parctice to split the core constraint from the not null constraint validation ..." As examples we have @Email and @Length, but would the same not apply for @NotEmpty. From a programmers point of view I think @NotEmpty should return true for null values. However, one could argue that from a GUI perspective it would not make sense to get to different validation messages. In fact, a user does not know what it means that the value cannot be null. However, any decent GUI/web framework will make sure that a string value will always be passed as empty string when nothing is entered by the user. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-6) Wrong example in validation methods section

by Hardy Ferentschik (JIRA)

Wrong example in validation methods section ------------------------------------------- Key: BVAL-6 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-6 Project: Bean Validation Issue Type: Bug Components: spec-general Reporter: Hardy Ferentschik Section 4.1.1.1 Examples - there is a @NotNull missing for adressline2, since in the explanation says:"the following code will return three InvalidConstraint objects. One for addressline1 violating NotNull, one for addressline2 violating NotNull and one for city violating Length. Either the example or the explanation needs updating. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-53) Context API should be renamed to make room for ValidationContext in VF.createValidation

by Emmanuel Bernard (JIRA)

Context API should be renamed to make room for ValidationContext in VF.createValidation --------------------------------------------------------------------------------------- Key: BVAL-53 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-53 Project: Bean Validation Issue Type: Bug Components: spec-general Reporter: Emmanuel Bernard -- 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, 1 month

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3583) Crietia API with empty Disjunction expressions doesn't work in a natural way

by Darryl Miles (JIRA)

Crietia API with empty Disjunction expressions doesn't work in a natural way ---------------------------------------------------------------------------- Key: HHH-3583 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3583 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.3.1 Reporter: Darryl Miles Priority: Minor Attachments: hib-with-EmptyMode.diff An empty Disjunction() expression in a Criteria API query results in a statement of: SELECT foo FROM table WHERE (foo.someColumn='someValue') OR (1=1) The reason for the "1=1" is due to the implict Conjunction() which is the default for criteria.add(Expression.something()).add(Expression.something()) Thinking through this problem domain until conclusion you end up at the question "How should an empty Junction be handled (in respect of its enclosing expression) ?" This is akin to SQL NULL type handling, i.e. NULL value is not a value; an "empty expression" is not an expression. Looking a the problem from the point of view what mades the most natural and straight forward Critiera API the natural expectation is for an empty expression to have no observable effect on the result set. This depends on the nature of the enclosing Junction the expression belongs to (is it Conjunction() or Disjunction() ?). The next issue you have to deal with is what if you have nested empty expressions, the natural way a user expects it to work is to resolve an Junction graph of empty expressions to a single empty expression, for example "((() OR ()) AND () AND (() OR ()))" is equivalent to "()". The notation "()" refers to an empty expression. So then it is necessary to deal with recursion. In some situations it maybe necessary/desired to dictate what to do with an empty expression, for example wanting to always treat the result as a logical TRUE, or logical FALSE in your expression graph on a Junction() by Junction() basis. Please find attached a patch with 2 new testcases that will resolve the unnatural behavior observed when an empty Disjunction() is used in a Criteria API expression. The testcases cover testing a number of nesting scenarios. Should this patch be reviewed and approved the only external change from the previous version should be when an empty Disjunction() added into the expression of a Critiera API query it should return less data than before, since the "OR (1=1)" expression will become "OR (1=0)". Due to the previous behavior the additions I now make in creating EmptyMode at the same time are just not visible. Please also advise if any additional documentation is needed citing references to the section/files/javadoc where I can document this feature/change best. -- 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, 1 month

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1936) IdentityGenerator doesn't support BigInteger as a valid identity type.

by Andrew Thompson (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936?page=c... ] Andrew Thompson commented on HHH-1936: -------------------------------------- We couldn't find a way to change that field. > IdentityGenerator doesn't support BigInteger as a valid identity type. > ---------------------------------------------------------------------- > > Key: HHH-1936 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Hibernate 3.0.5, Sybase 12.05, Window/ Unix > Reporter: Leonid Shtivelman > > Identity generator strategy doesn't support BigInteger as a valid id type. This causes problem with Sybase which requires identity column to be numeric. It would seem an obvious way to get around this problem is to set column mapping to long in hibernate xml and the actual java object. This will solve obvious problem of creating identity, but will cause performance problem on selection. In order for Sybase to use index for parameter query the variable type of the parameter and column index type has to be the same. If ones maps column type to Long, Hibernate will use JDBC method setLong(long) to set value in the prepared statement. This will cause mismatch between parameter type and column index type, and Sybase will not use index to locate index. As you can see this is a big problem for anyone that is using identity columns Sybase and Hibernate -- 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, 1 month

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1829) Allow join on any property using property-ref

by Edward Borner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?page=c... ] Edward Borner commented on HHH-1829: ------------------------------------ Does anyone have a suggested work around for this issue? Or an ETA for a fix in the product? Thanks, Ed > Allow join on any property using property-ref > --------------------------------------------- > > Key: HHH-1829 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829 > Project: Hibernate Core > Issue Type: New Feature > Components: metamodel > Affects Versions: 3.2.0 cr1, 3.2.0.cr2 > Reporter: Maarten Winkels > Assignee: Steve Ebersole > Attachments: AbstractJoinTest.java, HHH-1829-mwinkels.patch, hhh-1829.patch, JoinNoPropertyRefTest.java, JoinPropertyRefTest.java, Person.hbm.xml, Person.java, PersonNoPropertyRef.hbm.xml > > > Currently joining tables for one class (uing the <join...> tag) is only supported for the id property. The property-ref is allowed on the <key..> tag inside the <join..> tag, but this is ignored. -- 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, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2008