[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
16 years, 10 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
16 years, 10 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
16 years, 10 months
[Hibernate-JIRA] Created: (HHH-2524) Criteria query with collection of values (Set<java.lang.String>)
by marco molinari (JIRA)
Criteria query with collection of values (Set<java.lang.String>)
----------------------------------------------------------------
Key: HHH-2524
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2524
Project: Hibernate3
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.2
Environment: Java VM : 1.5.0_07
DBMS : HSQLDB
Hibernate: hibernate-3.2.2.ga
Reporter: marco molinari
Hi to all,
I have a problem with Criteria query on collection of values.
Below I wrote a piece of java code and a piece of Person.hbm.xml.
I want to search all persons with the email addresses containing character '@'.
I obtain an empty list of Person and the SQL created by Criteria seems not correct ( more or less ... WHERE lower(PERSON_ID) ? ).
I search information inside Hibernate site and Hibernate book but I didn't found the solution.
public class Person
{
private Long id;
private Set<String> emailAddresses = new HashSet();
public Set<String> getEmailAddresses()
{
return emailAddresses;
}
public void setEmailAddresses(Set<String> emailAddresses) {
this.emailAddresses = emailAddresses;
}
}
public static void main(String[] args)
{
List<Person> list = session.createCriteria(Person.class)
.add( Restrictions.ilike( "emailAddresses", "@", MatchMode.ANYWHERE ) )
.list();
}
Piece of Person.hbm.xml:
<set name="emailAddresses" table="'PERSON_EMAIL_ADDR'" inverse="true">
<key column="'PERSON_ID'"/>
<element column="'EMAIL_ADDR'" type="java.lang.String" not-null="true"/>
</set>
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2855) Error during a entity collection loading - wrong SQL query generation - missing discriminator condition in the "where" clause for a specific subclass
by Peter Fassev (JIRA)
Error during a entity collection loading - wrong SQL query generation - missing discriminator condition in the "where" clause for a specific subclass
-----------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2855
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2855
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Reporter: Peter Fassev
Priority: Critical
Attachments: testcase.zip
There is a problem, when loading a entity collection (bag), when the collection element is a subclass. The query, witch fetches the elements of the collection, does not use the discriminator value of a subclass and thus loads also other elements form different classes. Please look at the simple test case I have provided.
Here is a simple description:
Having a base class A with two subclasses AA and AB, the class A has many-to-one connection to another base class B. The class B itself has two different collections (bags), the first contains only AA elements, the second bag BB elements. The classes AA and AB has different integer properties.
When I try to load an instance of class B, which is connected to some AA and AB instances, and than try to access the list of all connected AA instances, there is an exception, because Hibernate tries to load all AA and AB instances in one and the same AA collection. The exception is actually thrown, because Hibernate tries to instanciate an AA instance from a AB data! This is the case, because the selection query, which is generated automatically by Hibernate, does not use the discriminator value of the AA subclass to load the collection, and thus selects the AA and AB elements from the database.
WORKAROND: Currently, the only workaround i found is to define a "where" parameter in the hibernate-mapping with for each collection with the appropriated subclass discriminator.
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-2650) Allow for an entire Session to be readOnly, add Session.setReadOnly() method
by Gunther Schadow (JIRA)
Allow for an entire Session to be readOnly, add Session.setReadOnly() method
----------------------------------------------------------------------------
Key: HHH-2650
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2650
Project: Hibernate3
Issue Type: Sub-task
Components: core
Environment: Any
Reporter: Gunther Schadow
There is a need for read-only applications to avoid any snapshoting of objects if that application never intends to make updates. Such readOnly mode would be the mode in which any object gets loaded into the session, whether directly or from lazy collections. The use case is reporting applications which want to make sure that they don't even accidentally make updates AND that want to save the time it takes to create snapshots because they read through a lot of data very quickly. Our own need is that we have a rich client where we hold read only sessions open for browsing and where we spawn off any change transactions into separate Sessions. Even in change transactions we like to have all objects locked from even accidental updates unless they are explicitly unlocked.
A Session.setReadOnly() method would be ideal to do this. It does not appear very hard to make that improvement. We would do it ourselves even if we had some idea if (and under which criteria) our modifications would have a chance to make it into future versions of 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, 11 months
[Hibernate-JIRA] Created: (ANN-632) @IndexColumn doesn't set value of index column
by Dan Allen (JIRA)
@IndexColumn doesn't set value of index column
----------------------------------------------
Key: ANN-632
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-632
Project: Hibernate Annotations
Issue Type: Bug
Components: documentation
Affects Versions: 3.3.0.ga
Reporter: Dan Allen
I'm sure I will get screamed at for this, but the @IndexColumn just doesn't work with @OneToMany. When I say it doesn't work, it means that I am a reasonable person and I have studied the documentation for at least 4 hours and I just cannot figure out how to make it work. So either the documentation needs to be improved, or there is something wrong with Hibernate. I refuse to believe that I am this stupid.
Here is my problem in a nutshell. I have a Person and a collection of Jobs. The Jobs should be an indexed list based on the history that the person holds them.
@Entity
public class Person {
@Id @GeneratedValue
private long id;
@Column
private String name;
@OneToMany(cascade=ALL, fetch=LAZY, mappedBy = "job")
@IndexColumn(base = 1, name = "order")
private List<Job> jobs = new ArrayList<Job>();
// getters and setters
}
@Entity
public class Job {
@Id @GeneratedValue
private long id;
@Column
private String name;
@ManyToOne
@JoinColumn(name="person_id")
private Person person;
@Column
private Integer order;
// getters and setters
}
If I do the following, I get NULL for order.
Person person = new Person();
person.setName("Chuck")
Job job1 = new Job();
job1.setName("sysadmin")
job1.setPerson(person);
person.getJobs().add(job1);
Job job2 = new Job();
jobs2.setName("network admin")
job2.setPerson(person);
person.getJobs().add(job2);
entityManager.persist(person);
Assume that the reason I am not assigning an order is more complex than this example. The point is that we want to see the order column populated with the index of the list.
Now, if you give me the business about removing mappedBy, to that I will respond that by removing mappedBy, Hibernate tries to work with a person_job table, which I don't want. I want two tables, one for person and one for job.
--
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, 11 months