[Hibernate-JIRA] Created: (HHH-5955) Add support to @OrderColumn JPA2 annotation to work with @AuditMappedBy
by benoit heinrich (JIRA)
Add support to @OrderColumn JPA2 annotation to work with @AuditMappedBy
-----------------------------------------------------------------------
Key: HHH-5955
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5955
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.6.1, 3.6.0
Environment: jboss 6.0.0.Final and hibernate 3.6.0.Final
Reporter: benoit heinrich
Hi guys,
I'm working on a project where we're using envers and since we're migrating from jboss 4.2.3 to jboss 6.0.0.Final (finally), I'm then upgrading the old envers to the new one.
Part of the migration I've changed all the @IndexColumn by the new JPA2 @OrderColumn and it seems that envers doesn't work with that new annotation (or I might do something wrong here )
Also, since we're now using the @OrderColumn the "position" column on the referenced entity has been removed as the hibernate documentation (and JPA2 specs) ask for it. Since it's been removed I'm getting the problem.
Here is the example mapping:
{code}
@Entity
@Audited
public class OrganizationEntity {
@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "org_entity_id", columnDefinition = "int", nullable = false)
@OrderColumn(name = "position", columnDefinition = "tinyint", nullable = false)
@AuditMappedBy(mappedBy = "organizationEntity", positionMappedBy = "position")
private List contactDetailList;
}
@Entity
@Audited
public class OrganizationEntityContactDetail {
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "org_entity_id", columnDefinition = "int", nullable = false, insertable = false, updatable = false)
private OrganizationEntity organizationEntity;
}
{code}
Every time I deploy this I'm getting the following error:
{code}
Caused by: org.hibernate.HibernateException: could not init listeners
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:205) :3.6.0.Final
at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1980) :3.6.0.Final
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1842) :3.6.0.Final
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:902) :3.6.0.Final
... 73 more
Caused by: org.hibernate.MappingException: @AuditMappedBy points to a property that doesn't exist: com.example.services.organization.entity.OrganizationEntityAddress.position
at org.hibernate.envers.configuration.ClassesAuditingData.forcePropertyInsertable(ClassesAuditingData.java:83)
at org.hibernate.envers.configuration.ClassesAuditingData.updateCalculatedFields(ClassesAuditingData.java:72)
at org.hibernate.envers.configuration.EntitiesConfigurator.configure(EntitiesConfigurator.java:86)
at org.hibernate.envers.configuration.AuditConfiguration.(AuditConfiguration.java:97)
at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:129)
at org.hibernate.envers.event.AuditEventListener.initialize(AuditEventListener.java:335)
at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198) :3.6.0.Final
at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181) :3.6.0.Final
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194) :3.6.0.Final
... 76 more
{code}
More details can be read there: http://community.jboss.org/message/589031
Thanks for looking at it :)
Cheers,
/Benoit
--
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
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-6324) Hibernate one-to-many relationship together with Oracle integrity referential
by lorenzo pergolini (JIRA)
Hibernate one-to-many relationship together with Oracle integrity referential
-----------------------------------------------------------------------------
Key: HHH-6324
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6324
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0
Environment: JBoss 6.0 standard community edition. Eclipese Helios. Hibernate 3.6.0.
Reporter: lorenzo pergolini
Attachments: model.PNG
We defined a one to many relationship between two tables: Role and RoleAccount.
We managed the integrity referential directly on Oracle.
Our need is to delete one or more RoleAccount related to a Role, but we also need to keep an Oracle integrity referential when we try to delete a Role that has at least a RoleAccount linked.
So what we expect from Hibernate is that there would exist a cascade option, besides delete and delete-orphan, that when trying to delete a Role that has at least a RoleAccount, it doesn't delete first the orphans and then the parents, but the opposite so to raise an integrity referential exception.
Instead if we use delete-orphan option, Hibernate first deletes all the orphan children(RoleAccounts) and then delete the parent(Role), without raising any Oracle integrity referential exception.
We know that this can be done by removing the delete option from cascade (cascade="save-update"), but then we manually have to delete RoleAccounts.
Below I attached part of the mappings and integrity referential sql script:
<!----------------Role -------------->
<bag name="roleFunctions" table="`AdmRoleFunction`" inverse="true" fetch="select" cascade="save-update">
<key>
<column name="`admRoleId`" not-null="true" />
</key>
<one-to-many class="it.apra.logistic.model.admin.RoleFunction" />
</bag>
<!----------------RoleAccounts -------------->
<bag name="roleAccounts" table="`AdmRoleAccount`" inverse="false" fetch="select" cascade="save-update,delete">
<key>
<column name="`admRoleId`" not-null="true" />
</key>
<one-to-many class="it.apra.logistic.model.admin.RoleAccount" />
</bag>
<!------Integrity referential Sql-------------->
ALTER TABLE "AdmRoleAccount" ADD CONSTRAINT "FkAdmRole2" FOREIGN KEY ("admRoleId") REFERENCES "AdmRole" ("id") /
ALTER TABLE "AdmRoleAccount" ADD CONSTRAINT "FkAdmAccount2" FOREIGN KEY ("admAccountId") REFERENCES "AdmAccount" ("id") ON DELETE CASCADE /
--
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
12 years, 10 months
[Hibernate-JIRA] Created: (EJB-364) Composite PK and @GeneratedValue
by Radosław Smogura (JIRA)
Composite PK and @GeneratedValue
--------------------------------
Key: EJB-364
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-364
Project: Hibernate Entity Manager
Issue Type: Bug
Affects Versions: 3.3.2.GA
Environment: Hibernate 3.2.6
Glassfish
PostgreSQL
Reporter: Radosław Smogura
Priority: Critical
[code]
For class like this
@Entity
@IdClass(FooId.class)
/* Seq / Table generator */
public class Foo {
int id1;
int id2;
@Id
public getId1() {
return id1;
}
public setId1(....);
@Id
@GeneratedValue(strategy=AUTO/IDENTITY/SEQUENCE/TABLE)
public int getId2() {
return id2;
}
public void setId2(.....);
}
[/code]
Id1 is set manully, but id2 is unchanged i this situation hibernate doesn't generates PK and tries to insert NULL causing error.
Specification requires assigning of generated value with @Id properties. Part 2.4.1 defines two types of PKs simple and composite and part 9.1.9 says about PKs in generally. (SEQ or IDENTITY is specification depended, but PostgreSQL support it and Hibernate should support it too).
--
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
12 years, 10 months
[Hibernate-JIRA] Created: (HSEARCH-776) maxFacetCount returns incorrect results when ordering a faceted query
by Adrian Meredith (JIRA)
maxFacetCount returns incorrect results when ordering a faceted query
---------------------------------------------------------------------
Key: HSEARCH-776
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-776
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.0.Final
Environment: hibernate 3.6.4, hibernate search 3.4
Reporter: Adrian Meredith
Priority: Critical
When putting a restriction on facets such as
{code}
FacetingRequest fr = qb.facet().name("name").onField("someField").discrete().orderedBy(FacetSortOrder.COUNT_DESC).maxFacetCount(10).includeZeroCounts(false).createFacetingRequest();
{code}
I would expect the facets with the top 10 results to be returned which appears to be true but it seems some are randomly missing (like the 10 are somehow spread across all results as opposed to the top ten). Removing the max restriction and only returning the first ten entries shows the correct results.
for example
{code}
QueryBuilder qb = ftEm.getSearchFactory().buildQueryBuilder().forEntity(WebResult.class).get();
FacetManager fm = query.getFacetManager()
FacetingRequest fr = qb.facet().name("name").onField("someField.id").discrete().orderedBy(FacetSortOrder.COUNT_DESC).includeZeroCounts(false).createFacetingRequest();
fm.enableFaceting(fr);
fm.getFacets("name").subList(0, endIndex);
{code}
The two code examples should return the exact same thing but the don't. The below code is my workaround but as you can imaging this could potentially take a dangerous amount of memory due to it effectively loading the entire index.
My WebResult class has OneToOne relations to various other objects (e.g. country)
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-770) Range facets: .below on numeric null values (AssertionFailure: Unsupported range type)
by Elmer van Chastelet (JIRA)
Range facets: .below on numeric null values (AssertionFailure: Unsupported range type)
--------------------------------------------------------------------------------------
Key: HSEARCH-770
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-770
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.0.Final
Environment: Using Hibernate 3.4.0 final, independent on on platform.
Reporter: Elmer van Chastelet
Attachments: RangeFacetNumericNullValueFail.zip
An assertion failure ("Unsupported range type") is thrown, when getting facets ( facetmanager.getFacets( facetName ) ) after narrowing on a facet ( facetmanager.getFacetGroup( facetingName ).selectFacets( facet )) in the following situation:
- Using a range facet with _.below_ constraint
- on a _numeric field_ (i.e. has @NumericField annotation)
- the field has a _null_ value for at least one indexed entity
Attached is a unit test that throws this exception.
My guess is that entities with null values are included in the result of the below facet, so probably null is evaluated to be 'lower' than any valid Integer. The lowest value found is probably used somewhere to set some range during .selectFacets( facetName ). This range is then used again when calling .getFacets( facetingName ), which tries to obtain the type from a null value -> AssertionFailure: Unsupported range type.
RangeFacetNumericNullValueFail.zip includes a unit test (testRangeBelowWithNullValues() in org.hibernate.search.test.query.facet.RangeFacetingTest) and the modified files which are used by this test (like Truck.java)
Exception trace:
org.hibernate.annotations.common.AssertionFailure: Unsupported range type
at org.hibernate.search.query.dsl.impl.RangeFacetImpl.createNumericRangeQuery(RangeFacetImpl.java:146)
at org.hibernate.search.query.dsl.impl.RangeFacetImpl.getFacetQuery(RangeFacetImpl.java:55)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.createSelectionGroupQuery(FacetManagerImpl.java:160)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacetFilter(FacetManagerImpl.java:146)
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildFilters(HSQueryImpl.java:650)
at org.hibernate.search.query.engine.impl.HSQueryImpl.getQueryHits(HSQueryImpl.java:384)
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:275)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacets(FacetManagerImpl.java:110)
See also: [topic in Hibernate user forum|https://forum.hibernate.org/viewtopic.php?f=9&t=1011030]
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-3028) Memory consumption when query cache is enabled
by Markus Heiden (JIRA)
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate3
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety.
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-597) Inconsistent treatment of extended FullTextIndexEventListener
by Ben Dotte (JIRA)
Inconsistent treatment of extended FullTextIndexEventListener
-------------------------------------------------------------
Key: HSEARCH-597
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-597
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.2.0.Final
Environment: Hibernate 3.5.3, SQL Server 2005
Reporter: Ben Dotte
Priority: Minor
In my hibernate.cfg.xml file I have specified my own hibernate event listener class that extends from FullTextEventListener.java. ContextHelper nicely allows this (line 50):
if ( candidate instanceof FullTextIndexEventListener ) { ... }
However, with debug-level logging turned on, I see a number of log messages from EventSourceTransactionContext line 116 "FullTextIndexEventListener was not registered as FlushEventListener". This is because it looks for an exact class match:
if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { ... }
Could we change this to be FullTextIndexEventListener.class.isAssignableFrom(listener.getClass()) instead?
I also noticed an == check for the same thing in EventListenerRegister.isPresentInListeners().
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-681) NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor
by Katrin E. (JIRA)
NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor
--------------------------------------------------------------------------------------
Key: HSEARCH-681
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-681
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.3.0.Final
Environment: Master-Slave-Architecture
Reporter: Katrin E.
We have a master-slave-architecture which delegates an index update to the master. We have NumericFields in the index to perform NumericRangeQueries. When the slave tries to inform the master via JMSBackendQueueProcessor the object including a NumericField gets serialized. A NotSerializableException occurs on a NumericTokenStream. The NumericField extends AbstractField, which implements Serializable, but it cannot be serialized because it stores the precisionStep in the underlying NumericTokenStream, which is not serializable.
This might be a lucene issue, but Hibernate Search gets affected for NumericRangeQueries. There is an issue on the lucene jira as well but isn't resolved yet:
https://issues.apache.org/jira/browse/LUCENE-2707
Here is a code snippet to test the serialization of a NumericField:
NumericField number = new NumericField("number", 4);
number.setFloatValue(42f);
try {
FileOutputStream fout = new FileOutputStream("number.txt");
ObjectOutputStream oos = new ObjectOutputStream(fout);
oos.writeObject(number);
oos.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
--
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
12 years, 11 months