[Hibernate-JIRA] Created: (BVAL-10) Turn ValidatorParser into a MetadataProvider
by Emmanuel Bernard (JIRA)
Turn ValidatorParser into a MetadataProvider
--------------------------------------------
Key: BVAL-10
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-10
Project: Bean Validation
Issue Type: New Feature
Components: ri-general
Reporter: Emmanuel Bernard
Assignee: Hardy Ferentschik
You should turn parser into something more like a MetadataProvider.
I removed the getValidators() method from parser and moved it to ValidatorImpl. The parser should not be aware of ValidatorImpl, nor Validator for that matter.
The MetadataProvider will be an interface anybody can implement. We will do the annotation version as well as the XML version (and probably some kind of XML overriding annotation version) but one can imagine a Script / Groovy DSLed version, a Programmatic API version and so on.
I imagine a MetadataProvider instance can be passed during the building phase to the ValidatorFactory. The same instance would then be shared for all Validators (kind of make sense, you can't parse XML for every single ValdiatorImpl instantiation).
That woul mean the parser ode needs ot be reworked to be immutable (at least work in concurrent calls)
--
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
17 years, 2 months
[Hibernate-JIRA] Created: (HHH-3357) session.clear() takes too long
by Jay Erb (JIRA)
session.clear() takes too long
------------------------------
Key: HHH-3357
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3357
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.6, 3.2.5
Reporter: Jay Erb
Clearing a session that contains a large number of Proxies takes a very long time. The reason for this is that null is set on the LazyInitializer when clearing the StatefulPersistenceContext, whenever a new session is set on an AbstractLazyInitializer, a check is done to see if the AbstractLazyInitializer is still attached to its previous session (and correctly throws an exception if it is). This check performs a linear search through all Proxies in the PersistenceContext. Since we're setting the session to null, do we really need to do this expensive linear search?
I propose we not perform the linear search if the session being set on the AbstractLazyInitializer is null.
--
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
17 years, 2 months
[Hibernate-JIRA] Created: (HBX-1014) Could not load JPA Configuration
by Reto Urfer (JIRA)
Could not load JPA Configuration
--------------------------------
Key: HBX-1014
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1014
Project: Hibernate Tools
Issue Type: Bug
Components: consoleconfiguration
Affects Versions: 3.2.cr1
Environment: Hibernate 3.2.4, Hibernate Annotations 3.3.0, Hibernate EntityManager 3.3.1, Oracle 10g R2
Reporter: Reto Urfer
If the project name contains a <SPACE> character, the following exception occurs when you try to browse the console configuration:
org.hibernate.console.HibernateConsoleRuntimeException: Could not load JPA Configuration
at org.hibernate.console.ConsoleConfiguration.buildConfiguration(ConsoleConfiguration.java:499)
at org.hibernate.console.ConsoleConfiguration.access$0(ConsoleConfiguration.java:484)
at org.hibernate.console.ConsoleConfiguration$2.execute(ConsoleConfiguration.java:203)
at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:65)
at org.hibernate.console.ConsoleConfiguration.buildWith(ConsoleConfiguration.java:185)
at org.hibernate.console.ConsoleConfiguration.build(ConsoleConfiguration.java:106)
at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:38)
at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:97)
at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:103)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:196)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.hibernate.console.HibernateConsoleRuntimeException: Could not create JPA based Configuration
at org.hibernate.console.ConsoleConfiguration.buildJPAConfiguration(ConsoleConfiguration.java:142)
at org.hibernate.console.ConsoleConfiguration.buildConfiguration(ConsoleConfiguration.java:496)
... 10 more
Caused by: java.lang.reflect.InvocationTargetException
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.hibernate.console.ConsoleConfiguration.buildJPAConfiguration(ConsoleConfiguration.java:133)
... 11 more
Caused by: javax.persistence.PersistenceException: java.lang.IllegalArgumentException: Unable to visit JAR file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin. Cause: Illegal character in path at index 53: file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:258)
... 16 more
Caused by: java.lang.IllegalArgumentException: Unable to visit JAR file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin. Cause: Illegal character in path at index 53: file:/D:/Daten/eclipse33/LogicaCMG/workspace/Unittest JPA/bin
at org.hibernate.ejb.packaging.JarVisitor.getVisitor(JarVisitor.java:112)
at org.hibernate.ejb.Ejb3Configuration.getMainJarVisitor(Ejb3Configuration.java:266)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:239)
... 16 more
If the project is renamed so it does not contain any <SPACE> characters anymore it works fine.
This problem did not occur in Hibernate Tools 3.2 Beta11
--
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
17 years, 2 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
17 years, 2 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
17 years, 2 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
17 years, 2 months