[Hibernate-JIRA] Created: (HV-389) Support conditional validation at property level
by jason shi (JIRA)
Support conditional validation at property level
------------------------------------------------
Key: HV-389
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-389
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Affects Versions: 4.1.0.Final
Reporter: jason shi
Assignee: Hardy Ferentschik
In Oval, there is a "when" attribute in each ConstrainsChecker,which can be used for conditional check.
In the following example fieldB must not be null only if fieldA is not null as well. With the prefix groovy: it is indicated that the formula is expressed in the Groovy language.
{code}
public class BusinessObject
{
private String fieldA;
@NotNull(when = "groovy:_this.fieldA != null")
private String fieldB;
}
{code}
Although we can use ScriptAssert as a work-around, but ScriptAssert can't be used at property level validation, and the "when" attribute make the validation logical more clearly.
In UI layer validation, this feature is very important in instant UI validation.
The hibernate validator should have the ability to pass a ValueContext to the Validator,then we can write a custom Contrains to implement this feature.
--
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
13 years, 5 months
[Hibernate-JIRA] Created: (HBX-1081) Generation of meta attributes for composite-id
by Anders Reinhardt Hansen (JIRA)
Generation of meta attributes for composite-id
----------------------------------------------
Key: HBX-1081
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1081
Project: Hibernate Tools
Issue Type: Improvement
Components: reverse-engineer
Affects Versions: 3.2.beta11
Environment: All, not related to platform.
Reporter: Anders Reinhardt Hansen
Priority: Minor
The ReverseEngineeringStrategy has a method; "public Map tableToMetaAttributes(TableIdentifier tableIdentifier)"
This method returns a Map of meta tags which will be put inside the class node of the hbm files that are generated.
It would be a nice addition if we could have a method like this which placed meta tags inside the composite id node.
the method could be called "public Map tableToMetaAttributesForCompositeId(TableIdentifier tableIdentifier)"
An example of the problem is shown in the below example;
<class name="XXX1" table="XXX1">
<meta attribute="generated-class">XXX1Base</meta> <!-- this can be generated by tableToMetaAttributes() -->
<composite-id name="XXX2" class="XXX2">
<meta attribute="generated-class">XXX2Base</meta> <!-- this cannot be generated -->
<key-property name="propertyXXX" type="int">
<column name="ColoumnXXX" />
</key-property>
<key-property name="YYY" type="int">
<column name="ColoumnYYY" />
</key-property>
</composite-id>
...
</class>
The issue was discussed on the forum in topic http://forum.hibernate.org/viewtopic.php?t=989476
--
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
13 years, 5 months
[Hibernate-JIRA] Created: (OGM-63) Remove unused code branches and unnecessary null checks
by Juraci Paixao Krohling (JIRA)
Remove unused code branches and unnecessary null checks
-------------------------------------------------------
Key: OGM-63
URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-63
Project: Hibernate OGM
Issue Type: Improvement
Components: core
Affects Versions: 3.0.0.Alpha1
Reporter: Juraci Paixao Krohling
Assignee: Juraci Paixao Krohling
Fix For: 3.0-next
I ran the FindBugs code analysis tool and noticed that there are some unnecessary null checks and unused code branches in Hibernate OGM Core module, like the following example from OgmLoader:
{code:title=OgmLoader.java}
//we don't load more than one instance per row, shortcircuiting it for the moment
final int[] collectionOwners = null;
for ( int i=0; i<collectionPersisters.length; i++ ) {
final CollectionAliases[] descriptors = getCollectionAliases();
final boolean hasCollectionOwners = collectionOwners !=null &&
collectionOwners[i] > -1;
//true if this is a query and we are loading multiple instances of the same collection role
//otherwise this is a CollectionInitializer and we are loading up a single collection or batch
final Object owner = hasCollectionOwners ?
row[ collectionOwners[i] ] :
null; //if null, owner will be retrieved from session
final CollectionPersister collectionPersister = collectionPersisters[i];
final Serializable key;
if ( owner == null ) {
key = null;
}
else {
key = collectionPersister.getCollectionType().getKeyOfOwner( owner, session );
//TODO: old version did not require hashmap lookup:
//keys[collectionOwner].getIdentifier()
}
readCollectionElement(
owner,
key,
collectionPersister,
descriptors[i],
resultSet, //TODO CURRENT must use the same instance across all calls
session
);
{code}
Note that {{collectionOwners}} is always {{null}}. Thus, {{hasCollectionOwners}} is always {{false}}, causing {{owner}} to always be {{null}}. Then, the {{if ( owner == null ) }} will always be evaluated as true, turning the else part to be unnecessary. The above code can be rewritten as:
{code:title=OgmLoader.java}
final CollectionAliases[] descriptors = getCollectionAliases(); // this line was inside the for loop... it seems it can be outside
for ( int i=0; i<collectionPersisters.length; i++ ) {
final CollectionPersister collectionPersister = collectionPersisters[i];
readCollectionElement(
null,
null,
collectionPersister,
descriptors[i],
resultSet, //TODO CURRENT must use the same instance across all calls
session
);
}
{code}
This JIRA is to track similar issues to the example above.
--
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
13 years, 5 months
[Hibernate-JIRA] Created: (HHH-3305) hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
by Jim Doyle (JIRA)
hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
-------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305
Project: Hibernate3
Issue Type: Bug
Components: metamodel
Affects Versions: 3.2.1
Reporter: Jim Doyle
In SQL Server 2005, PRIMARY KEY defaults to creating a Clustered Index for the PK column at table creation time.
To confirm this behaviour Please see: http://msdn.microsoft.com/en-us/library/ms188066.aspx
This default behaviour is un-desireable for a number of reasons:
1. No other databases default to a clustered IDX at the PK ; Not DB2, nor Oracle nor MySQL
2. There may only be ONE clustered IDX per table. By using this as a default makes it difficult
for the app developer or DBA to quickly add or change the once-per-table opportunity to use
the cluster to improve query performance.
3. The default cluster index that Microsoft applies seems only to benefit naive SQL server users with
little to no DBA skills. Table insert of new rows onto a Clustered Index PK is always very fast and
while this optimization may be impressive if your problem space is rapidly inserting new data into large tables,
this optimization is often an antipattern to users with more plausible query patterns such as scan by non-primary
key date, numeric amounts or alphabetical data.
4. Defaulting the PK to clustered creates SUBSTANTIAL burden for a DBA when the Clustered Index needs to be removed
from the PK to be deployed on other columns on the table. As an example of the burden that this creates, for EACH TABLE
one must:
- Discover all tables and columns that link back to the table in question through FOREIGN KEY
- Drop all foreign keys
- Drop the PK
- Add the PK back, with NONCLUSTERED
- Put back all the dropped Foreign keys
5. Additional arguments against supporting Microsoft's unusual default is given here:
http://tonesdotnetblog.wordpress.com/2008/05/26/twelve-tips-for-optimisin...
(Please See Section 2: Use Clustered Index).
I propose ANY ONE of the following enhancements to the DDL generator for the SQL Server 2005 Dialect:
1. Change the generated SQL from colname coltype PRIMARY KEY TO colname coltype PRIMARY KEY NONCLUSTERED such that
PK index generate conforms the the usual, sensible defaults of other database products.
2. Use a Properties attribute (i.e. hibernate.hbm2ddl.dialect.mssql.use_non_clustered_pk) that is evaluated at hbm2ddl runtime
that will emit 'NONCLUSTERED' to the PK clause. If this Property is not defined, the hbm2ddl will simply emit PRIMARY KEY as it does
now and MS SQL Server will use its peculiar and annoying default.
--
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
13 years, 5 months