[Hibernate-JIRA] Created: (HV-52) unified unit testing pattern for standalone validators
by Sanne Grinovero (JIRA)
unified unit testing pattern for standalone validators
------------------------------------------------------
Key: HV-52
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-52
Project: Hibernate Validator
Issue Type: Patch
Affects Versions: 3.0.0.ga
Reporter: Sanne Grinovero
Priority: Minor
Attachments: validator-testing-cleanup.patch
Hi,
I've seen some bugs in the validator I would like to help solving, but the main issue I've seen is that to
write unittests the code is quite verbose; the consequence is that mission-critical code is well tested
but most trivial code is untested.
It looks like to me that most JIRA issues here are relevant to this "untested trivial" code...
I would appreciate if you could apply this patch that greatly simplifies writing of unit tests for standalone validators,
as I would like to send some more patches using this code to develop test-first.
This affects only the "test" source, diffed from 3.0.0.GA, and includes some new testing of
@NotEmpty and @Digits; I would add much more tests if you're not against it.
With "standalone validators" i mean that this is not useful for graph/integration testing,
just each validator on some property.
Sanne
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HV-42) Reference Documentation: broken example
by Robert Spielmann (JIRA)
Reference Documentation: broken example
---------------------------------------
Key: HV-42
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-42
Project: Hibernate Validator
Issue Type: Bug
Components: documentation
Reporter: Robert Spielmann
Priority: Trivial
The Hibernate Validator Reference Guide (Hibernate Validator 3.0.0.GA) contains examples for writing custom annotations and validators, section 1.4 "writing your own constraints". There, it says that the class CapitalizedValidator implements Validator<Capitalized> and PropertyConstraint. The example class, however, does not implement the "apply" method. Thus, the example class does not compile.
Additionally, the class "Capitalize" (containing constants like FIRST) is not defined anywhere. This leaves the example incomplete and thus - unless you quickly implement this class - unsuable for practical experiments.
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HV-25) Generated DDL ignores Validator annotations on component fields and superclass fields
by Ben Anderson (JIRA)
Generated DDL ignores Validator annotations on component fields and superclass fields
-------------------------------------------------------------------------------------
Key: HV-25
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-25
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 3.0.0.ga
Environment: Windows XP, Hibernate 3.2.4.sp1, Hibernate Annotations 3.3.0.ga, Postgres, HSQL
Reporter: Ben Anderson
Attachments: model.zip
The DDL generated for entities containing components or superclass properties does not reflect any Validator length restrictions or not-null constraints that have been defined on those component or superclass properties i.e. a component with a property containing the @Length(max = 50) and @NotNull annotation is generated as varchar(255) with nulls permitted (at the database level).
I've posted a more detailed example to the forum at http://forum.hibernate.org/viewtopic.php?t=975612
Another example can be found at http://www.ibm.com/developerworks/web/library/j-hibval.html - the SQL generated when this schema is exported is:
create table cc (id integer not null, fname varchar(255), mi varchar(255), lname varchar(255), addr1 varchar(255), addr2 varchar(255), city varchar(255), zipcode varchar(255), state_id varchar(255), cvv2 varchar(6) not null, expiration_date timestamp not null, type_id integer not null, num varchar(30) not null, customer_id integer not null, primary key (id));
create table customer (id integer not null, dob timestamp, phone varchar(255), fax varchar(255), email varchar(255), fname varchar(255), mi varchar(255), lname varchar(255), addr1 varchar(255), addr2 varchar(255), city varchar(255), zipcode varchar(255), state_id varchar(255), primary key (id));
The SQL should be:
create table cc (id integer not null, fname varchar(30) not null, mi varchar(1), lname varchar(30) not null, addr1 varchar(50) not null, addr2 varchar(50), city varchar(50) not null, zipcode varchar(15) not null, state_id varchar(2) not null, cvv2 varchar(6) not null, expiration_date timestamp not null, type_id integer not null, num varchar(30) not null, customer_id integer not null, primary key (id));
create table customer (id integer not null, dob timestamp, phone varchar(13), fax varchar(13), email varchar(40), fname varchar(30) not null, mi varchar(1), lname varchar(30) not null, addr1 varchar(50) not null, addr2 varchar(50) not null, city varchar(50) not null, zipcode varchar(15) not null, state_id varchar(2) not null, primary key (id));
I've attached the relevant classes from this example.
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HV-22) Provide contextual validation
by Emmanuel Bernard (JIRA)
Provide contextual validation
-----------------------------
Key: HV-22
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-22
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Emmanuel Bernard
The basic idea is to have a special parameter in annotations named context(s)
@NotNull(message="doh", context = {"screen1Input", "screen2Input", "default"})
"default" being a special context, the one applied every time (including in the DDL)
no context or an empty context is equivalent to "default"
The regular API are running against "default"
Override the regular APIs with getInvalidValues(..., String context);
Not entirely sure the idea will float, but it sounds like a non invasive way to do it.
PS this might require to create @[Name]s annotations ie @NotNulls({@NotNull(message="m1", context="earlyStage"), @NotNull(message="m2")})
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HV-28) "connection already null in cleanup" when using validators
by David J. M. Karlsen (JIRA)
"connection already null in cleanup" when using validators
----------------------------------------------------------
Key: HV-28
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-28
Project: Hibernate Validator
Issue Type: Bug
Environment: hibernate annotations 3.3.0ga
hibernate validator 3.0.0ga
hibernate 3.2.4.sp1
hibernate-commons-annotations 3.3.0.ga
Reporter: David J. M. Karlsen
Priority: Critical
2007-06-27 21:18:39,133 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.impl.SessionImpl - opened session at timestamp: 11829719154 (SessionImpl.java:220)
2007-06-27 21:18:39,159 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.DefaultSaveOrUpdateEventListener - saving transient instance (DefaultSaveOrUpdateEventListener.java:158)
2007-06-27 21:18:39,162 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractSaveEventListener - generated identifier: e2632934-a800-4a91-a9ff-ce8e1f95a03d, using strategy: org.hibernate.id.Assigned (AbstractSaveE
ventListener.java:112)
2007-06-27 21:18:39,168 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractSaveEventListener - saving [mypackage.server.types.Fee#e2632934-a800-4a91-a9ff-ce8e1f95a03d] (AbstractSaveEventListener.java:
153)
2007-06-27 21:18:39,228 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - flushing session (AbstractFlushingEventListener.java:58)
2007-06-27 21:18:39,232 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - processing flush-time cascades (AbstractFlushingEventListener.java:111)
2007-06-27 21:18:39,237 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - dirty checking collections (AbstractFlushingEventListener.java:154)
2007-06-27 21:18:39,238 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Flushing entities and processing referenced collections (AbstractFlushingEventListener.java:171)
2007-06-27 21:18:39,249 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Processing unreferenced collections (AbstractFlushingEventListener.java:210)
2007-06-27 21:18:39,251 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - Scheduling collection removes/(re)creates/updates (AbstractFlushingEventListener.java:224)
2007-06-27 21:18:39,252 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - Flushed: 1 insertions, 0 updates, 0 deletions to 1 objects (AbstractFlushingEventListener.java:85)
2007-06-27 21:18:39,254 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.event.def.AbstractFlushingEventListener - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections (AbstractFlushingEventListener.java:91)
2007-06-27 21:18:39,260 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.pretty.Printer - listing entities: (Printer.java:83)
2007-06-27 21:18:39,262 [WorkManager.DefaultWorkManager : 0] DEBUG org.hibernate.pretty.Printer - mypackage.types.Fee{<values anonymized>} (Printer.java:90)
2007-06-27 21:18:39,264 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.event.def.AbstractFlushingEventListener - executing flush (AbstractFlushingEventListener.java:290)
2007-06-27 21:18:39,265 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - registering flush begin (ConnectionManager.java:469)
2007-06-27 21:18:39,276 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - registering flush end (ConnectionManager.java:478)
2007-06-27 21:18:39,278 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.impl.SessionImpl - after transaction completion (SessionImpl.java:422)
2007-06-27 21:18:39,280 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.impl.SessionImpl - closing session (SessionImpl.java:273)
2007-06-27 21:18:39,281 [WorkManager.DefaultWorkManager : 0] TRACE org.hibernate.jdbc.ConnectionManager - connection already null in cleanup : no action (ConnectionManager.java:375)
2007-06-27 21:18:39,298 [WorkManager.DefaultWorkManager : 0] ERROR Could not insert Fee
org.hibernate.validator.InvalidStateException: validation failed for: mypackage.server.types.Fee
at org.hibernate.validator.event.ValidateEventListener.validate(ValidateEventListener.java:148)
at org.hibernate.validator.event.ValidateEventListener.onPreInsert(ValidateEventListener.java:172)
at org.hibernate.action.EntityInsertAction.preInsert(EntityInsertAction.java:156)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:49)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
This only seems to happen when I'm running inside an appserver (WebSphere 6.1) with pooled connections - in my unit-tests using a org.springframework.jdbc.datasource.DriverManagerDataSource (eg. non-pooled) it works OK - and only if adding validating annotations (@NotEmpty)
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HV-37) Validating a lazy collection of composite-elements causes flush problem
by Ian Long (JIRA)
Validating a lazy collection of composite-elements causes flush problem
------------------------------------------------------------------------
Key: HV-37
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-37
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 3.0.0.ga
Environment: Hibernate 3.2.4ga
Hibernate Annotations 3.3.0.ga
mysql 5.0.27
Reporter: Ian Long
Using the event listeners(pre-update,pre-insert) in hibernate, a problem occurs when validating a lazy collection of composite-elements.
I was using the @Size validator, but I'm sure others will cause the same problem.
For example:
<set name="activatedModules"
lazy="true"
table="location_module_activation">
<key column="location_id" />
<composite-element class="com.opterus.opscenter.model.module.ActivatedModule" >
<property name="activationDate" column="activate_date" not-null="true" />
<many-to-one name="module" class="com.opterus.opscenter.model.module.Module" column="module_id" not-null="true" unique="false" />
</composite-element>
</set>
will cause an exception during flush:
01:53:55,587 ERROR [http-8080-Processor23] AssertionFailure:22 - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection [com.opterus.opscenter.model.common.Brand.regions] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
Since it tries to access the proxied collection. A collection of entity objects does not cause this problem.
I guess the composite-element is handled differently than regular collections?
Filed at the request of emmanuel, from the following thread: http://forum.hibernate.org/viewtopic.php?p=2361829#2361829
--
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
15 years, 11 months
[Hibernate-JIRA] Created: (HHH-3599) Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"
by Dirk Lachowski (JIRA)
Materializing proxy fails non-deterministic with "[-4000] (at 10): Unknown result table"
----------------------------------------------------------------------------------------
Key: HHH-3599
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3599
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: MaxDB 7.6.05.09, Linux, JDBC
Reporter: Dirk Lachowski
We have a quite simple domain object:
@Entity
@Table(name = "cc_user_assignment")
@org.hibernate.annotations.Proxy(lazy = true)
public class CostCenterUserAssignment {
private Long id;
private Contact contact;
private Set<CostCenter> costCenter = new HashSet<CostCenter>();
private CostCenter defaultCostCenter;
@ManyToMany
@JoinTable(name = "j_cc_user2user", joinColumns = { @JoinColumn(name = "user_assignment_id") }, inverseJoinColumns = @JoinColumn(name = "cost_center_id"))
public Set<CostCenter> getCostCenter() {
return costCenter;
}
public void removeCostCenter(CostCenter ccRemove) {
costCenter.remove(ccRemove);
}
}
Most of the time the call to "removeCostCenter()" succeeds, but now we have a non-reproducible situation where the call to costCenter.remove(ccRemove) fails. It seems to be data-dependend as it occurs in one of our productive systems. There it is reproducible for one set of data. First we thought it is dependent on the data-size but we are not able to reproduce it by simply creating another dataset of the same size.
The select created for the proxy-materializing is:
select
costcenter0_.user_assignment_id as user1_10_,
costcenter0_.cost_center_id as cost2_10_,
costcenter1_.id as id169_0_,
costcenter1_.accountNumber as accountN2_169_0_,
costcenter1_.balance as balance169_0_,
costcenter1_.balance_currency as balance4_169_0_,
costcenter1_.budget as budget169_0_,
costcenter1_.budget_currency as budget6_169_0_,
costcenter1_.budgetExcessAllowed as budgetEx7_169_0_,
costcenter1_.bdg_extra as bdg8_169_0_,
costcenter1_.bdg_extra_currency as bdg9_169_0_,
costcenter1_.budgetPeriod as budgetP10_169_0_,
costcenter1_.customer_id as customer13_169_0_,
costcenter1_.manager_id as manager14_169_0_,
costcenter1_.name as name169_0_,
costcenter1_.transferBudget as transfe12_169_0_,
customer2_.id as id167_1_,
customer2_.accountId as accountId167_1_,
customer2_.addr_id as addr16_167_1_,
customer2_.attribute01 as attribute3_167_1_,
customer2_.attribute02 as attribute4_167_1_,
customer2_.attribute03 as attribute5_167_1_,
customer2_.attribute04 as attribute6_167_1_,
customer2_.attribute05 as attribute7_167_1_,
customer2_.attribute06 as attribute8_167_1_,
customer2_.attribute07 as attribute9_167_1_,
customer2_.attribute08 as attribute10_167_1_,
customer2_.attribute09 as attribute11_167_1_,
customer2_.attribute10 as attribute12_167_1_,
customer2_.delivery_lock_id as delivery17_167_1_,
customer2_.externalAccountId1 as externa13_167_1_,
customer2_.externalAccountId2 as externa14_167_1_,
customer2_.owner_id as owner18_167_1_,
customer2_.pricelist_id as pricelist19_167_1_,
customer2_.pricingSchemaName as pricing15_167_1_,
address3_.id as id165_2_, address3_.city as city165_2_,
address3_.country_id as country16_165_2_,
address3_.fax as fax165_2_,
address3_.fon as fon165_2_,
address3_.houseNumber as houseNum5_165_2_,
address3_.mail as mail165_2_,
address3_.name1 as name7_165_2_,
address3_.name2 as name8_165_2_,
address3_.name3 as name9_165_2_,
address3_.name4 as name10_165_2_,
address3_.postbox as postbox165_2_,
address3_.postcode as postcode165_2_,
address3_.postcodeCompany as postcod13_165_2_,
address3_.postcodePostbox as postcod14_165_2_,
address3_.street as street165_2_,
address3_.title_id as title17_165_2_,
country4_.id as id159_3_,
country4_.isoCode as isoCode159_3_,
country4_.name as name159_3_,
title5_.id as id163_4_,
title5_.isOrganization as isOrgani2_163_4_,
title5_.name as name163_4_,
deliverylo6_.id as id191_5_,
deliverylo6_.autoDeliveryLock as autoDeli2_191_5_,
deliverylo6_.description as descript3_191_5_,
deliverylo6_.messageLock as messageL4_191_5_,
deliverylo6_.name as name191_5_,
deliverylo6_.orderLock as orderLock191_5_,
deliverylo6_.reservationLock as reservat7_191_5_,
pricelistt7_.id as id175_6_,
pricelistt7_.description as descript2_175_6_,
pricelistt7_.name as name175_6_,
contact8_.id as id166_7_,
contact8_.customer_id as customer12_166_7_,
contact8_.firstName as firstName166_7_,
contact8_.ignoreAssortment as ignoreAs3_166_7_,
contact8_.lastName as lastName166_7_,
contact8_.officeFax as officeFax166_7_,
contact8_.officeMail as officeMail166_7_,
contact8_.officeMobile as officeMo7_166_7_,
contact8_.officePhone as officePh8_166_7_,
contact8_.role as role166_7_,
contact8_.title_id as title13_166_7_,
contact8_.webPassword as webPass10_166_7_,
contact8_.webUserName as webUser11_166_7_,
customer9_.id as id167_8_,
customer9_.accountId as accountId167_8_,
customer9_.addr_id as addr16_167_8_,
customer9_.attribute01 as attribute3_167_8_,
customer9_.attribute02 as attribute4_167_8_,
customer9_.attribute03 as attribute5_167_8_,
customer9_.attribute04 as attribute6_167_8_,
customer9_.attribute05 as attribute7_167_8_,
customer9_.attribute06 as attribute8_167_8_,
customer9_.attribute07 as attribute9_167_8_,
customer9_.attribute08 as attribute10_167_8_,
customer9_.attribute09 as attribute11_167_8_,
customer9_.attribute10 as attribute12_167_8_,
customer9_.delivery_lock_id as delivery17_167_8_,
customer9_.externalAccountId1 as externa13_167_8_,
customer9_.externalAccountId2 as externa14_167_8_,
customer9_.owner_id as owner18_167_8_,
customer9_.pricelist_id as pricelist19_167_8_,
customer9_.pricingSchemaName as pricing15_167_8_,
title10_.id as id163_9_,
title10_.isOrganization as isOrgani2_163_9_,
title10_.name as name163_9_
from
j_cc_user2user costcenter0_,
cost_center costcenter1_,
KNA1 customer2_,
ADDR address3_,
C005 country4_,
CSAD3 title5_,
delivery_lock deliverylo6_,
sd_pr_prltype pricelistt7_,
KNVK contact8_,
KNA1 customer9_,
CSAD3 title10_
where
costcenter0_.cost_center_id=costcenter1_.id(+)
and costcenter1_.customer_id=customer2_.id(+)
and customer2_.addr_id=address3_.id(+)
and address3_.country_id=country4_.id(+)
and address3_.title_id=title5_.id(+)
and customer2_.delivery_lock_id=deliverylo6_.id(+)
and customer2_.pricelist_id=pricelistt7_.id(+)
and costcenter1_.manager_id=contact8_.id(+)
and contact8_.customer_id=customer9_.id(+)
and contact8_.title_id=title10_.id(+)
and costcenter0_.user_assignment_id=?
The same query can be successfully submitted using database studio.
Maybe it's related to this:
http://osdir.com/ml/db.maxdb/2004-10/msg00199.html
A full stack trace is available here:
http://jira.lacho.net/jira/browse/ES-579
--
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
15 years, 11 months