[Hibernate-JIRA] Created: (ANN-747) @CollectionOfElements does not cascade on delete
by Nicole Rauch (JIRA)
@CollectionOfElements does not cascade on delete
------------------------------------------------
Key: ANN-747
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-747
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.1.GA
Environment: Hibernate 3.2.6 GA
Database: H2 1.0.72
Reporter: Nicole Rauch
Consider the following constellation:
@Embeddable
public class Foo {
// ...
}
@Entity
public class Bar {
@CollectionOfElements
private Set<Foo> myFoos;
// ...
}
When I persist a Bar object that contains some Foos, and when I later decide to delete the Bar object, I get a foreign key constraint violation error message because the Foo objects, which contain a reference to the Bar object that owns them, are not deleted automatically. I would expect the default behaviour to be "on delete cascade" because the Foo objects are embeddables, thus they cannot exist on their own without the Bar object that owns them. But there is no way to tell Hibernate to cascade:
- the @OnDelete annotation is only allowed for OneToMany relations
- the @Cascade annotation is being ignored
- there is no "cascade" property for the CollectionOfElements
So my question is: Why does the cascading not occur automatically, and how do I tell Hibernate to cascade anyways?
Thanks a lot in advance,
Nicole
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3273) One-to-Many relationship not working with custom Loader
by Darren Hicks (JIRA)
One-to-Many relationship not working with custom Loader
--------------------------------------------------------
Key: HHH-3273
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3273
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1
Environment: hibernate-3.2.6.jar
Reporter: Darren Hicks
Within the context of a One-to-Many relationship, NamedQueryCollectionInitializer .initialize() never actually populates the PersistantBag on the parent after it calls query.setCollectionKey( key ).setFlushMode( FlushMode.MANUAL ).list() to retrieve the children.
This is documented in the forums here: http://forums.hibernate.org/viewtopic.php?t=986428
Additionally, the poster has a fix posted which may solve the problem, or at least lay out the groundwork for a solution. Here is the proposed implementation of NamedQueryCollectionInitializer.initialize():
public void initialize(Serializable key, SessionImplementor session)
throws HibernateException {
if (log.isDebugEnabled()) {
log.debug("initializing collection: " + persister.getRole()
+ " using named query: " + queryName);
}
// TODO: is there a more elegant way than downcasting?
AbstractQueryImpl query = (AbstractQueryImpl) session
.getNamedSQLQuery(queryName);
if (query.getNamedParameters().length > 0) {
query.setParameter(query.getNamedParameters()[0], key, persister
.getKeyType());
} else {
query.setParameter(0, key, persister.getKeyType());
}
List list = query.setCollectionKey(key).setFlushMode(FlushMode.MANUAL)
.list();
// Uh, how 'bout we save the collection for later retrieval?
CollectionKey collectionKey = new CollectionKey(persister, key, session
.getEntityMode());
for (Object object : session.getPersistenceContext()
.getCollectionsByKey().keySet()) {
if (collectionKey.equals(object)) {
PersistentCollection persistentCollection = session
.getPersistenceContext().getCollection(collectionKey);
Serializable[] serializables = new Serializable[list.size()];
for (int i = 0; i < list.size(); i++) {
serializables[i] = persister.getElementType().disassemble(
list.get(i), session,
persistentCollection.getOwner());
}
persistentCollection.initializeFromCache(persister,
serializables, persistentCollection.getOwner());
persistentCollection.setSnapshot(key, persistentCollection
.getRole(), serializables);
persistentCollection.afterInitialize();
session.getPersistenceContext().getCollectionEntry(
persistentCollection).postInitialize(
persistentCollection);
}
}
}
--
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, 6 months
[Hibernate-JIRA] Created: (EJB-328) Missing flush before lock() when LockModeType is AUTO
by Per Olesen (JIRA)
Missing flush before lock() when LockModeType is AUTO
-----------------------------------------------------
Key: EJB-328
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-328
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.3.1.GA
Environment: core: 3.2.5.ga
entitymanager: 3.3.1.ga
annotations: 3.3.0.ga
Reporter: Per Olesen
Priority: Minor
When I try to WRITE lock() a newly persisted entity using entityManager.lock, I get a StaleObjectStateException, telling me that some other transaction updated or deleted the row. I am doing this in the same transaction (persist and lock).
By digging into the code, I see that the exception is thrown inside the SelectLockingStrategy.lock method, around these lines:
ResultSet rs = st.executeQuery();
try {
if ( !rs.next() ) {
if ( factory.getStatistics().isStatisticsEnabled() ) {
factory.getStatisticsImplementor()
.optimisticFailure( lockable.getEntityName() );
}
throw new StaleObjectStateException( lockable.getEntityName(), id );
}
}
The query executed here is the one which performs the select on id with FOR UPDATE. This select finds nothing, hence the exception.
Setting show_sql = true shows me, that no insert is performed. Debugging the flush mode tells me, that it is set to AUTO.
Shouldn't AUTO flush mode have the side effect, that a flush is performed before a query?
Performing an explicit flush, before the lock, makes everything green :-), so this is my current work-around.
Here is the exception (sanitized for company info):
org.springframework.orm.jpa.JpaOptimisticLockingFailureException: nested exception is javax.persistence.OptimisticLockException
Caused by: javax.persistence.OptimisticLockException
at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:643)
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:600)
at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:379)
...
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.foo.bar#32]
at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:78)
at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1334)
at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:88)
at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64)
at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584)
at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576)
at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:376)
...
--
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, 6 months
[Hibernate-JIRA] Created: (HBX-1092) hbm2doc with graphing fails on MacOSX
by Avram Cherry (JIRA)
hbm2doc with graphing fails on MacOSX
-------------------------------------
Key: HBX-1092
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1092
Project: Hibernate Tools
Issue Type: Bug
Components: hbm2doc
Affects Versions: 3.2.0.GA, 3.2.2
Reporter: Avram Cherry
In the method org.hibernate.tool.hbm2x.DocExporter.dotToFile, the portions of the command passed to Runtime.exec() are being passed to an escape(String) method that optionally adds quotes to the executable file path and the path to the input file, but only if the OS is not linux. MacOSX is not linux, but adding quotes causes exec() to fail.
The solution is to change the following statement:
String exeCmd = escape(dotExeFileName) + " -T" + getFormatForFile(outFileName) + " " + escape(dotFileName) + " -o " + escape(outFileName);
to:
String[] exeCmd = new String[] {dotExeFileName, " -T", getFormatForFile(outFileName), dotFileName, " -o ", outFileName};
If you pass the command and arguments as separate strings within an array to Runtime.exec() you do not need to quote filenames, regardless of platform.
A (potentially very harmful) workaround is to pass -Dos.name=Linux to the VM.
Please note that I've checked both the 3.2 branch and trunk and both contain the same problem.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3007) Unchanged persistent set gets marked dirty on session.merge()
by Lars Koedderitzsch (JIRA)
Unchanged persistent set gets marked dirty on session.merge()
-------------------------------------------------------------
Key: HHH-3007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Reporter: Lars Koedderitzsch
Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection.
This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush.
I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace().
Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line:
Object result = target == null || target == original ? instantiateResult( original ) : target;
The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet).
In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet.
This way the PersistentSet remains marked dirty.
A workaround is to manually clear the dirty state of an immutable collection after merge but before flush.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-3527) Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl
by Paul FitzPatrick (JIRA)
Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl
-------------------------------------------------------------------------------------------------
Key: HHH-3527
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3527
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.1
Environment: 3.3.1 GA, Postgres 8.3.3, EH Cache
Reporter: Paul FitzPatrick
Priority: Minor
When the SessionFactoryImpl constructor builds the EntityPersister for classes, it consults a cache of entityAccessStrategies for all the known second level cache regions. If only some of the classes in that region have version tags, then it is possible the cached EntityRegionAccessStrategy will be created without a Version Comparator. Subsequent calls to load an object using a Criteria query failed with a NullPointerException (stack trace below). The line being executed is "return version!=null && comparator.compare(version, newVersion) < 0;" and in this case "version" is an Integer object and comparator is null.
Not sure the appropriate solution. It would seem from an examination of the code that if the EntityRegionAccessStrategy is to be shared, then all classes in the second level cache region _must_ either all have a "version" column or all have no "version" column. Further, it seems implied that if they use a "version" column, then they must all use the exact same data type. If this is the case, then a better error check on the configuration data may be in order.
Caused by: java.lang.NullPointerException
at org.hibernate.cache.ReadWriteCache$Item.isPuttable(ReadWriteCache.java:426)
at org.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:180)
at org.hibernate.cache.impl.bridge.EntityAccessStrategyAdapter.putFromLoad(EntityAccessStrategyAdapter.java:68)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:179)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877)
at org.hibernate.loader.Loader.doQuery(Loader.java:752)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
at org.hibernate.loader.Loader.list(Loader.java:2120)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:328)
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-2097) LAZY property results in org.hibernate.TransientObjectException after merge
by Reto Urfer (JIRA)
LAZY property results in org.hibernate.TransientObjectException after merge
---------------------------------------------------------------------------
Key: HHH-2097
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2097
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: Hibernate3.2 cr4 with Annotations cr2 and EntityManager cr2, Oracle10g R2, WindowsXP
Reporter: Reto Urfer
Priority: Critical
Attachments: BugLazyPropertyMerge.zip
Entity1 has a property e2 which references Entity2. This property is defined as follows.
@ManyToOne(fetch = FetchType.LAZY, optional = false)
private Entity2 e2;
If you have an instance e1 of Entity1 which has not initialized property e2 and you merge e1 to the EntityManager within a transaction, then you get the following exception during commit:
Exception in thread "main" javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:63)
at com.test.Test.main(Test.java:42)
Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.test.Entity1.e2 -> com.test.Entity2
at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:350)
at org.hibernate.engine.Cascade.cascade(Cascade.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:130)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:53)
... 1 more
I added a small Testproject to reproduce this bug.
--
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, 8 months
[Hibernate-JIRA] Created: (HBX-1042) Make DocHelper robust against failing buildSettings()
by Arnout Engelen (JIRA)
Make DocHelper robust against failing buildSettings()
-----------------------------------------------------
Key: HBX-1042
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1042
Project: Hibernate Tools
Issue Type: Improvement
Components: hbm2doc
Reporter: Arnout Engelen
Attachments: dochelper.diff.txt
DocHelper calls cfg.buildSettings(). to get the Dialect, default catalog name and default schema name.
However, cfg.buildSettings() may fail with a HibernateException (example below).
It would be nice to have DocHelper handle this more gracefully. Attached is a simple patch that does this.
(background: I'd like to use the Configuration I'm getting from a Spring LocalSessionFactoryBean, which after initial creation leaves its LocalDataSourceConnectionProvider in a state that yiels a HibernateException when calling 'configure()' on it, which buildSettings() does. Because of this issue, I cannot use the DocExporter for my Spring-based hibernate configurations)
--
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, 8 months
[Hibernate-JIRA] Created: (HSEARCH-115) Add a default value for indexing null value
by Julien Brulin (JIRA)
Add a default value for indexing null value
-------------------------------------------
Key: HSEARCH-115
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-115
Project: Hibernate Search
Issue Type: Improvement
Components: mapping
Reporter: Julien Brulin
Hi,
Null elements are not indexed by lucene then it's not easy to use a nullable property in lucene query.
I have a TagTranslation entity in my model with a nullable property language. In this case null is used as default language for tag translation.
Each translation may have many variations like synonyms.
Because I can specified a default value for null value in the @Field annotation like this @Field(index=Index.UN_TOKENIZED, store=Store.NO, default='null'), i can't search a cat tag with a default translation like this : +value:cat* +lang:null
<pre></code>
@Entity()
@Table(name="indexing_tag_trans")
@org.hibernate.annotations.Cache(usage=org.hibernate.annotations.CacheConcurrencyStrategy.READ_WRITE)
@Indexed
public class TagTranslation implements java.io.Serializable {
private static final long serialVersionUID = -1065316566731456110L;
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@DocumentId
private Integer id;
@Field(index=Index.UN_TOKENIZED, store=Store.NO)
private String language;
@Field(index=Index.TOKENIZED, store=Store.YES)
private String value;
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.LAZY)
@org.hibernate.annotations.Fetch(org.hibernate.annotations.FetchMode.SUBSELECT)
@JoinColumn(name="translation_id")
@IndexedEmbedded
private List<TagVariation> variations = new LinkedList<TagVariation>();
public TagTranslation() { }
...
</code>
</pre>
What do you think about that ?
Ps: sorry for english write, i am a french guy.
--
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, 8 months
[Hibernate-JIRA] Created: (ANN-668) Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
by Clint Popetz (JIRA)
Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
------------------------------------------------------------------------------------------------
Key: ANN-668
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-668
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Hibernate 3.2.X, no database needed (happens during factory build before connecting to db)
Reporter: Clint Popetz
Attachments: propertyTypeExtractorBug.tar.gz
The following source:
@javax.persistence.Entity
public class TestEntity {
@javax.persistence.Id
public int Id;
public java.util.ArrayList<Object[]> badMethod() { return null; }
public static void main(String args[]) {
new org.hibernate.cfg.AnnotationConfiguration().addAnnotatedClass(TestEntity
.class).configure().buildSessionFactory();
}
}
will cause:
java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.toXType(JavaReflectionManager.java:164)^M
at org.hibernate.annotations.common.reflection.java.JavaXMethod.create(JavaXMethod.java:18)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.getXMethod(JavaReflectionManager.java:128)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethods(JavaXClass.java:114)
at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:214)
at org.hibernate.validator.ClassValidator.<init>(ClassValidator.java:133)
at org.hibernate.validator.event.ValidateEventListener.initialize(ValidateEventListener.java:91)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:356)
at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1304)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
Changing the return type to List<Object[]> avoids the bug.
Attached is a tgz of an ant-buildable project; typing "ant run" will illustrate the bug.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-2319) StatelessInterceptor
by Max Rydahl Andersen (JIRA)
StatelessInterceptor
--------------------
Key: HHH-2319
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2319
Project: Hibernate3
Type: New Feature
Components: core
Versions: 3.2.1
Reporter: Max Rydahl Andersen
It would make sense to have an Interceptor for StatelessSession to solve the following usecases:
Log/adjust SQL: onPrepareStatement
Proper entityname handling: instantiate/getEntity
Maybe also tx interaction: afterTransationBegin/beforeTransactionCompletion/afterTransactionCompletion
Technically it could be solved by just allowing to pass in a normal interceptor to a StatelessSession and just
document that the state oriented callbacks will not be called. Alternatively we can create a StatelessInterceptor that
only implement the releavant methods and wrap that instance into an internal Interceptor.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-2007) Hibernate doesn't support optional one-to-one associations
by Andrei Iltchenko (JIRA)
Hibernate doesn't support optional one-to-one associations
----------------------------------------------------------
Key: HHH-2007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2007
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Reporter: Andrei Iltchenko
Hibernate doesn't properly support optional one-to-one associations, e.g. Person (0..1) -- (0..1) Passport.
The Hibernate books and reference all talk of two ways of mapping one-to-one associations:
1. using a many-to-one fk association with a unique constraint on the fk;
2. using a pk association.
the trouble with both of them is that they enforce the mandatory property of an association end, which sometimes is not desirable. The first way enforces the mandatory property with the uniqueness constraint on the fk, the other by using the fact that one table's pk is its fk.
I tried to see if I could adapt the 1st way of representing one-to-ones to
support optional association ends. What I did was simply remove the unique and not null constrains from DDL generated (without removing it it would be impossible to have a Person record that doesn't reference a Passport record):
from
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NOT NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
UNIQUE(PassUniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
to
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
but leave the uniqueness attribute in the mapping file:
<many-to-one
name="pass"
class="application.business.logic.Passport"
cascade="save-update,merge"
unique="true"
>
<column name="PassUniqueId"/>
</many-to-one>
The resulting solution worked fine and I was able to create instances of Person not linked to a Passport. However Hibernate didn't succed in keeping the association from degrading into a many-to-one. It enabled me to create two Persons linked with the same Passport:
PASSUNIQUEID | VIRSION | UNIQUEID | Name
================================================
0d8b3919fffff | 1 | 0d5fb1dcfff | John
0d8b3919fffff | 0 | 10fd07bdfff | Sam
A subsequent attempt at retrieving such Persons with Hibernate failed:
org.hibernate.HibernateException: More than one row with the given identifier was found: 0d8b3919ffffffd60151e135b6da0164, for class: application.business.logic.Passport.
Hibernate should be able to impose the single end property of such associations without relying on the underlying RDBMS engine and never allow them to degrade to many-to-ones.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-2835) Setting org.hibernate.type logging to debug produces no logging
by Jeremy Grodberg (JIRA)
Setting org.hibernate.type logging to debug produces no logging
---------------------------------------------------------------
Key: HHH-2835
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2835
Project: Hibernate3
Issue Type: Bug
Components: core, documentation
Affects Versions: 3.2.5, 3.2.4
Environment: Hibernate 3.2.4.ga and Hibernate 3.2.5.ga with MySQL5Dialect (configured with Hibernate Annotations 3.3.0.ga and Spring 2.0.6)
Reporter: Jeremy Grodberg
Priority: Minor
According to the online documentation (labeled as version 3.2.2 at this moment), Table 3.9 "Hibernate Log Categories", as viewed here today:
http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat...
Setting the log4j category "org.hibernate.type" to debug should "Log all JDBC parameters". However, it produces no output at all.
When I go on to set "org.hibernate" to debug, I get output like this:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG: org.hibernate.SQL - select count(*) from album where genreID=?
DEBUG: org.hibernate.loader.Loader - bindNamedParameters() 126 -> genreId [1]
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG: org.hibernate.loader.Loader - result row:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close ResultSet (open ResultSets: 1, globally: 1)
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
Note that the JDBC parameters are logged under org.hibernate.loader but nothing appears under org.hibernate.type. FYI, genreId is, in this case, a Long.
Perhaps this is expected/desired when using annotations? If so, then please update the documentation. If not, please restore the logging.
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-2228) ant eg fails - bad release notes quick start
by Brian Brooks (JIRA)
ant eg fails - bad release notes quick start
--------------------------------------------
Key: HHH-2228
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2228
Project: Hibernate3
Type: Bug
Components: documentation
Versions: 3.2.0.ga
Environment: hibernate 3.2.0.ga
Microsoft Windows XP [Version 5.1.2600]
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode)
Reporter: Brian Brooks
Priority: Minor
The hibernate 3.2.0.ga release notes
http://sourceforge.net/project/shownotes.php?release_id=455849&group_id=4...
read as
Get Up And Running Quick
------------------------
Demo:
(1) copy your JDBC driver to the lib directory
(2) edit etc/hibernate.properties
(3) run "ant eg" or "build eg"
(4) browse the sourcecode in eg/org/hibernate/auction
This directions are incorrect. Below is the ant output if these steps are followed. Also, I had to put junit*.jar and antlr*all*.jar in my ANT_HOME/lib before ant eg would work.
C:\hibernate-3.2>ant eg
Buildfile: build.xml
[taskdef] Could not load definitions from resource clovertasks. It could not b
e found.
eg:
[javac] Compiling 8 source files to C:\hibernate-3.2\build\eg
[javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:10: cannot find
symbol
[javac] symbol : class FetchMode
[javac] location: package org.hibernate
[javac] import org.hibernate.FetchMode;
[javac] ^
[javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:11: cannot find
symbol
[javac] symbol : class FlushMode
[javac] location: package org.hibernate
[javac] import org.hibernate.FlushMode;
[javac] ^
[javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:12: cannot find
symbol
[javac] symbol : class LockMode
[javac] location: package org.hibernate
[javac] import org.hibernate.LockMode;
[javac] ^
....
--
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, 9 months
[Hibernate-JIRA] Created: (HBX-1068) Hibernate Configurations on Eclipse Ganymede 3.4
by Ricardo M Augusto (JIRA)
Hibernate Configurations on Eclipse Ganymede 3.4
------------------------------------------------
Key: HBX-1068
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1068
Project: Hibernate Tools
Issue Type: Bug
Components: eclipse
Affects Versions: 3.2.1
Environment: Windows Vista 32bits, hibernate 2.6, eclipse 3.4 (Ganymede)
Reporter: Ricardo M Augusto
When created hibernate configuration eclipse shows:
java.lang.NoClassDefFoundError: org/eclipse/ui/internal/util/SWTResourceUtil
at org.hibernate.eclipse.console.workbench.xpl.AnyAdaptableLabelProvider.getImage(AnyAdaptableLabelProvider.java:166)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getImage(WrappedViewerLabelProvider.java:117)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:165)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:932)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1012)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:466)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:880)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2041)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:827)
at org.eclipse.jface.viewers.AbstractTreeViewer.createAddedElements(AbstractTreeViewer.java:340)
at org.eclipse.jface.viewers.AbstractTreeViewer.internalAdd(AbstractTreeViewer.java:270)
at org.eclipse.jface.viewers.TreeViewer.internalAdd(TreeViewer.java:652)
at org.hibernate.eclipse.console.viewers.xpl.MTreeViewer.add(MTreeViewer.java:106)
at org.eclipse.ui.progress.DeferredTreeContentManager$3.runInUIThread(DeferredTreeContentManager.java:353)
at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3096) Count operator with idenfication variable w/ composite primary key produces bad sql
by Bob Tiernay (JIRA)
Count operator with idenfication variable w/ composite primary key produces bad sql
------------------------------------------------------------------------------------
Key: HHH-3096
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3096
Project: Hibernate3
Issue Type: Bug
Reporter: Bob Tiernay
@EmbeddedId
private Id id;
@Embeddable
public static class Id implements Serializable {
private static final long serialVersionUID = 6475618094377929936L;
@Column(name="TG_ID", nullable = false)
private Integer groupId;
@Column(name="MBR_ID", nullable = false)
private Integer memberId;
public Id() {
// Empty
}
public Id(Integer groupId, Integer memberId) {
super();
this.groupId = groupId;
this.memberId = memberId;
}
@Override
public boolean equals(Object other) {
if (other == this) {
return true;
} else if (other instanceof Id) {
return groupId.equals(((Id) other).groupId)
&& memberId.equals(((Id) other).memberId);
}
return false;
}
@Override
public int hashCode() {
return groupId.hashCode() ^ memberId.hashCode();
}
}
@NamedQuery(name = "GroupMember.getCountByGroup", query = "SELECT COUNT(gm) FROM GroupMember gm WHERE gm.id.groupId = :groupId")
produces
Hibernate: /* named HQL query GroupMember.getCountByGroup */ select count((groupmembe0_.TG_ID, groupmembe0_.MBR_ID)) as col_0_0_ from GROUP_MEMBER groupmembe0_ where groupmembe0_.TG_ID=?
and the following hibernate exception
Caused by: java.sql.SQLException: ORA-00907: missing right parenthesis
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:810)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:850)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1134)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3384)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
at org.hibernate.loader.Loader.doQuery(Loader.java:674)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader
Which is consistent with what Oracle produces by manual query execution. The problem is the extra set of parenthesis around the composite primary key columns which appear to be invalid (at least for Oracle)
The recommend fix would be to use COUNT(*) or count(groupmembe0_.TG_ID, groupmembe0_.MBR_ID) in yhis case
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3187) Issue with Hibernate3.0 and weblogic8.1 while setting transaction is marked to setRollbackOnly... (AppSetRollbackOnlyException)
by Anjan Deb (JIRA)
Issue with Hibernate3.0 and weblogic8.1 while setting transaction is marked to setRollbackOnly... (AppSetRollbackOnlyException)
-------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3187
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3187
Project: Hibernate3
Issue Type: Task
Affects Versions: 3.0 final
Environment: hibernate3.0, weblogic8.1, oracle9.1
Reporter: Anjan Deb
I am using Hibernate 3.0 with JTA (Weblogic 8.1 SP4).
Basically, I am trying to handle transaction/hibernate exceptions in my application.
I am managing transactions with UserTransaction. I start a transaction at the begining of the request and after that I am doing some operations on that transaction. And if some exception comes I log it, rollback the transaction and throw the exception.
UserTransaction.commit() throws RollbackException if anything goes wrong with the operation, but, it does not return what exactly went wrong, like, exceptions related to SQL Exception or hibernate Exception. It basically dumps all that information to the logs internally and throws RollbackException with the following trace (see below). But this trace has no such information which I can send back to the user. As, information of what went wrong has already been dumped to the server console.
I will appreciate if you can tell if there is anyway I can recieve the actual exception trace or am I doing anything wrong with the hibernate configuration??
Thanks in Advance,
Anjan
------------------------------------------------------------------------------------------------------------------------------
Actual Exception which transaction dumps to the server console/log
ERROR - ORA-00001: unique constraint (NOVATXN.UQ_BROKERS) violated
ERROR - ORA-00001: unique constraint (NOVATXN.UQ_BROKERS) violated
ERROR - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:353)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1216)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1990)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:275)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (NOVATXN.UQ_BROKERS) violated
at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:367)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:8726)
at weblogic.jdbc.wrapper.PreparedStatement.executeBatch(PreparedStatement.java:169)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
... 27 more
RollbackException Trace:
03/17/2008 08:50:09 [EROR] JTATransactionalAction weblogic.transaction.RollbackException: Unknown reason - with nested exception:
[weblogic.transaction.internal.AppSetRollbackOnlyException]
03/17/2008 08:50:09 [EROR] JTATransactionalAction com.novarum.nova.application.OperationException: Transaction does not exist
03/17/2008 08:50:09 [DBUG] MessageProcessor Unknown reason
java.lang.RuntimeException: Unknown reason
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:54)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Caused by: com.novarum.nova.application.OperationException: Unknown reason
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:35)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
... 10 more
Caused by: weblogic.transaction.RollbackException: Unknown reason - with nested exception:
[weblogic.transaction.internal.AppSetRollbackOnlyException]
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:325)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
... 11 more
getCause(): com.novarum.nova.application.OperationException: Unknown reason
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:35)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Caused by: weblogic.transaction.RollbackException: Unknown reason - with nested exception:
[weblogic.transaction.internal.AppSetRollbackOnlyException]
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:325)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
... 11 more
getCause(): weblogic.transaction.internal.AppSetRollbackOnlyException
at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:504)
at org.hibernate.transaction.CacheSynchronization.setRollbackOnly(CacheSynchronization.java:73)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:63)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1216)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1990)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:275)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Unknown reason - with nested exception:
[weblogic.transaction.internal.AppSetRollbackOnlyException]
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:325)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
getNested(): weblogic.transaction.internal.AppSetRollbackOnlyException
at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:504)
at org.hibernate.transaction.CacheSynchronization.setRollbackOnly(CacheSynchronization.java:73)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:63)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:115)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1216)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1990)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:275)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:246)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:303)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.ebw.nova.common.invoker.JTATransactionalAction.commit(JTATransactionalAction.java:31)
at com.ebw.nova.common.invoker.TransactionalAction.doAction(TransactionalAction.java:47)
at com.ebw.nova.common.invoker.ActionInvoker.invokeAction(ActionInvoker.java:21)
at com.ebw.nova.server.handler.AbstractRequestHandler.process(AbstractRequestHandler.java:73)
at com.ebw.nova.server.communication.jms.MessageProcessor.processRequest(MessageProcessor.java:44)
at com.ebw.ejb.mdb.MQManager.onMessage(MQManager.java:70)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Following is the hibernate.cfg.xml
<session-factory>
<!-- properties -->
<property name="connection.datasource">jdbc/novaJDBCDataSource</property>
<property name="transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
<property name="transaction.manager_lookup_class">org.hibernate.transaction.WeblogicTransactionManagerLookup</property>
<property name="dialect">org.hibernate.dialect.OracleDialect</property>
<property name="current_session_context_class">jta</property>
<property name="show_sql">false</property>
<property name="format_sql">true</property>
<property name="hibernate.default_schema">novatxn</property>
<property name="jdbc.batch_size">30</property>
<!-- jdbc.batch_versioned_data is set to false, making it true hibernate doesn't raise optimistic exception. -->
<property name="jdbc.batch_versioned_data">false</property>
<property name="jdbc.use_streams_for_binary">true</property>
<!-- Outer join fetching is used in MultiDArray-->
<property name="max_fetch_depth">1</property>
<property name="query.substitutions">true 1, false 0, yes 'Y', no 'N'</property>
<!--property name="cache.provider_class">org.hibernate.cache.EhCacheProvider</property-->
<!--#Using the Hibernate 2.1 query parser, because of Weblogic 8.1 ANTLR issue.-->
<property name="query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</property>
</session-factory>
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-2917) arithmatic of subselect throws NPE
by John Aylward (JIRA)
arithmatic of subselect throws NPE
----------------------------------
Key: HHH-2917
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2917
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5
Annotation 3.3.0
VAlidator 3.0.0
MySQL 5.0.44
Reporter: John Aylward
Exception Stack:
java.lang.NullPointerException
at org.hibernate.hql.ast.tree.BinaryArithmeticOperatorNode.getRightHandOperand(BinaryArithmeticOperatorNode.java:185)
at org.hibernate.hql.ast.tree.BinaryArithmeticOperatorNode.initialize(BinaryArithmeticOperatorNode.java:20)
at org.hibernate.hql.ast.HqlSqlWalker.prepareArithmeticOperator(HqlSqlWalker.java:1011)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.arithmeticExpr(HqlSqlBaseWalker.java:2729)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1278)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4041)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3600)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1762)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1690)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1687)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:577)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:228)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:160)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:111)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56)
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:72)
at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1623)
HQL:
[SELECT DISTINCT pi.billingAccount.consolidatedBillingAccount.bankAccount FROM com.cicat.bedrock.billing.model.ProviderInvoice AS pi WHERE pi.readyForPayment=true AND (SELECT piad.total FROM com.cicat.bedrock.billing.model.ProviderInvoiceAccountData AS piad WHERE piad.invoice = pi AND piad.providerBillingAccount = pi.billingAccount) > ((SELECT COALESCE(SUM(amount),0) FROM com.cicat.bedrock.billing.model.BankAccountTransaction AS bat1 WHERE bat1.deleted=false AND bat1.providerInvoice = pi) + (SELECT COALESCE(SUM(amount),0) FROM com.cicat.bedrock.billing.model.BankAccountTransactionSplit AS bats1 WHERE bats1.deleted=false AND bats1.bankAccountTransaction.deleted=false AND bats1.providerInvoice = pi)) ]
Representative SQL of HQL call:
SELECT DISTINCT ba.* from ProviderInvoice AS pi
INNER JOIN ProviderBillingAccount AS pba ON pi.billingAccount_id=pba.id
INNER JOIN ConsolidatedBillingAccount AS cba ON pba.consolidatedBillingAccount_id=cba.id
INNER JOIN BankAccount AS ba ON cba.bankAccount_id=ba.id
WHERE
pi.readyForPayment=true AND
(SELECT piad.total FROM ProviderInvoiceAccountData AS piad WHERE piad.invoice_id = pi.id AND piad.providerBillingAccount_id = pi.billingAccount_id)
>
((SELECT COALESCE(SUM(bat1.amount),0) FROM BankAccountTransaction AS bat1 WHERE bat1.deleted=false AND bat1.providerInvoice_id = pi.id)
+
(SELECT COALESCE(SUM(bats1.amount),0) FROM BankAccountTransactionSplit AS bats1 INNER JOIN BankAccountTransaction bat2 ON bats1.bankAccountTransaction_id=bat2.id WHERE bats1.deleted=false AND bat2.deleted=false AND bats1.providerInvoice_id = pi.id))
--
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, 9 months
[Hibernate-JIRA] Created: (HBX-849) Tools does not insert @Type in POJOs for user types defined in reveng.xml
by Zeljko Trogrlic (JIRA)
Tools does not insert @Type in POJOs for user types defined in reveng.xml
-------------------------------------------------------------------------
Key: HBX-849
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-849
Project: Hibernate Tools
Type: Bug
Components: hbm2java, reverse-engineer
Environment: jboss-seam-1.1.0.GA, MySQL
Reporter: Zeljko Trogrlic
I have created reveng.xml file:
<hibernate-reverse-engineering>
<table
catalog="configuration"
name="userdb_domain_acl">
<column name="enabled" type="com.siemens.msm.model.mapping.BooleanEnumType" exclude="false"/>
</table>
</hibernate-reverse-engineering>
and included it in build.xml:
<jdbcconfiguration propertyfile="build.properties"
packagename="${model.package}"
revengfile="${project.home}/reveng.xml"/>
Generated POJO attribute has proper type, but user type information is missing:
@Column(name = "enabled")
@Length(max = 42)
public Boolean getEnabled() {
....
so Hibernate reports error:
3:49:31,397 INFO [TableMetadata] table found: configuration.userdb_domain_acl
13:49:31,397 INFO [TableMetadata] columns: [id, enabled, tablename, domain]
13:49:31,397 WARN [ServiceController] Problem starting service persistence.units:ear=msmgui.ear,unitName=msmgui
javax.persistence.PersistenceException: org.hibernate.HibernateException: Wrong column type: enabled, expected: varchar(
2)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:698)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Annotations should look like this:
@Column(name = "enabled")
@Type(type="booleanEnum")
public Boolean getEnabled() {
...
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3227) Oracle's connect by syntax is mishandled when used with Filter
by Kyrill Alyoshin (JIRA)
Oracle's connect by syntax is mishandled when used with Filter
--------------------------------------------------------------
Key: HHH-3227
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3227
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.2.5
Environment: Hibernaet 3.2.5.GA, Oracle 10g.
Reporter: Kyrill Alyoshin
Basically, I have a filter definition on a class (via annotation), here it is:
@Filter(name = "limitInvoicesByAccountHolderHierarchy",
condition = "CHRG_ACCT_ID in (" +
"select ca1.chrg_acct_id from cv_chrg_acct ca1 " +
"inner join cv_org_unit og1 on ca1.acct_hldr_id = og1.org_unit_id " +
"where og1.org_unit_id in (" +
"select og2.org_unit_id from cv_org_unit og2 " +
"start with og2.org_unit_id = :root " +
" connect by prior og2.org_unit_id = og2.hier_par_org_unit_id" +
')' +
')'
It contains Oracle's "connect by" clause. Here is the SQL statement that Hibernate generates when trying to query invoices with the filter enabled:
Hibernate:
/*
from
Invoice */ select
invoice0_.inv_id as inv1_31_,
......
from
CV_INV invoice0_
where
invoice0_.CHRG_ACCT_ID in (
select
ca1.chrg_acct_id
from
cv_chrg_acct ca1
inner join
cv_org_unit og1
on ca1.acct_hldr_id = og1.org_unit_id
where
og1.org_unit_id in (
select
og2.org_unit_id
from
cv_org_unit og2 invoice0_.start invoice0_.with og2.org_unit_id = ? invoice0_.connect
by
invoice0_.prior og2.org_unit_id = og2.hier_par_org_unit_id
)
)
Even though the documentation states that the condition of the filter is pure SQL (which is great!), it still does not pass SQL verbatim but is actually trying to pre-process the following words: start, with, connect, prior.
Is there an easy work around to make Oracle10gDialect recognize these words?
Thanks a lot for looking into this!
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-2402) HQL generates inner join when selecting a specific attribute that is linked to another entity
by Peter Mutsaers (JIRA)
HQL generates inner join when selecting a specific attribute that is linked to another entity
---------------------------------------------------------------------------------------------
Key: HHH-2402
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2402
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Oracle 9i, affects ONLY version 3.2.2, was still working OK in version 3.2.1 and before.
Reporter: Peter Mutsaers
Priority: Critical
Mapping (note the lazy='false', it is essential to cause the problem):
<class name='Currency' lazy='false'>
....
</class>
<class name='Asset'>
<id name='id' ... </id>
<many-to-one name='currency' class='Currency' fetch='select'/>
</class>
The following HQL query: "select a.id, a.currency from Asset a"
used to generate a query on the Asset table, and subsequently generates separate queries on the Currency table.
Since version 3.2.2, this generates an inner join on Asset with Currency.
Now many Assets may have a NULL currency, so we do not get all records anymore!
This breaks logic and queries all over the place for us.
We can't go back to 3.2.1 due to other bugs that had been solved in 3.2.2.
The query "from Asset a" still works OK and as before, i.e. it makes the select only on the Asset table and afterwards fetches the Currency with individual selects.
I fear that an optimization has been made that has this negative side effect.
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3510) Sybase - Timestamp not being translated to the built-in database function
by Juraci Paixao Krohling (JIRA)
Sybase - Timestamp not being translated to the built-in database function
-------------------------------------------------------------------------
Key: HHH-3510
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3510
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Environment: Branch_3_2_4_SP1_CP and Sybase 15
Reporter: Juraci Paixao Krohling
Test Case: ComponentTest#testComponentQueries
Hibernate query "from Employee e where e.person = ('steve', current_timestamp)" should have translated "current_timestamp" to "getdate()" [1]:
14:49:11,087 DEBUG SQL:424 - select employee0_.ID as ID1_, employee0_.HIRE_DATE as HIRE2_1_, employee0_.name as name1_, employee0_.dob as dob1_, employee0_.value1 as value5_1_, employee0_.value2 as value6_1_ from T_EMP employee0_ where employee0_.name='steve' and employee0_.dob=current_timestamp
14:49:11,535 WARN JDBCExceptionReporter:77 - SQL Error: 207, SQLState: ZZZZZ
14:49:11,536 ERROR JDBCExceptionReporter:78 - Invalid column name 'current_timestamp'.
[1] SybaseDialect, line 58: registerFunction( "current_timestamp", new NoArgSQLFunction("getdate", Hibernate.TIMESTAMP) );
--
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, 9 months
[Hibernate-JIRA] Created: (HHH-3018) Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update.
by Nicolas Cazottes (JIRA)
Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update.
------------------------------------------------------------------------------------------------------------------------
Key: HHH-3018
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3018
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.5
Reporter: Nicolas Cazottes
Attachments: testXMLTypeUpdates.zip
While analyzing the SQL queries Hibernate generates to persist objects, I fall on a behaviour, that I first found strange, which is that in one flush of one transaction, there may be both an insert and an update for a given entity. My first expectation was to have only one insert and no update.
After a few search, I discover that conversation (http://forum.hibernate.org/viewtopic.php?p=2191664&sid=c571096bda4a6b636e...) that explains it is normal in the case of a save with modifications after save.
I discover (cf the classes of my zip showing it) that this behaviour is also present in the case of a relation that is managed by cascade. What I noticed is that the insert of the related entity is planned when the first hql query is executed after the relation has been established. So if the related entity is modified after the query execution (for exemple depending on the result of the query), an update will be executed.
This behaviour is understandable but in my case, the update is really expensive (because it acts on an XMLType column) and unless I set a FlushMode to COMMIT (which I found really not a good solution), I can not control that Hibernate will generate both an insert and an update or only an insert. I know I could also set the relation just before the commit in order to avoid insert+update but this solution is not possible in my case and I find it not elegant (it would break the semantic of the cascade of the relation).
I suggest to introduce a new configuration element (similar to the flushmode) in Hibernate in order to be able to have control whether Hibernate generates an insert containing the data of the entity at the first save or an insert containing the data of the entity at the flushing time.
Note : The attached files (which is the smallest extraction of what does my application) shows that behaviour both for the save call and the cascade declenched by a query.
Note2 : I found an issue in jira number 2621 submited by someone else that is related to this subject in think.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2426) Misleading logging messages when using ThreadLocalSessionContext
by Don Smith (JIRA)
Misleading logging messages when using ThreadLocalSessionContext
----------------------------------------------------------------
Key: HHH-2426
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2426
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Reporter: Don Smith
Priority: Minor
The log messages printed out by TransactionFactoryFactory and SettingsFactory are misleading when using ThreadLocalSessionContext:
2007-02-09 21:49:58,581 INFO [org.hibernate.transaction.TransactionFactoryFactory:info] Using default transaction strategy (direct JDBC transactions)
2007-02-09 21:49:58,588 INFO [org.hibernate.transaction.TransactionManagerLookupFactory:info] No TransactionManagerLookup Configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
2007-02-09 21:49:58,590 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic flush during beforeCompletion(): disabled
2007-02-09 21:49:58,591 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic session close at end of transaction: disabled
This does not indicate that sessions will be closed after commit, which is the behavior when using ThreadLocalSessionContext.
--
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, 10 months
[Hibernate-JIRA] Created: (ANN-682) @ForeignKey override of @MappedSuperclass
by Christian Bauer (JIRA)
@ForeignKey override of @MappedSuperclass
-----------------------------------------
Key: ANN-682
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-682
Project: Hibernate Annotations
Issue Type: New Feature
Components: binder
Reporter: Christian Bauer
Put this @ManyToOne in a @MappedSuperclass:
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "CREATED_BY_USER_ID", nullable = false)
// Ideally this foreign key should be ON DELETE SET NULL, however...
// Hibernate can't rename these so subclasses would get the same FK constraint name. This doesn't
// work, so we need to let Hibernate create a random identifier for these. We could fix this in the
// DatabaseObjects.hbm.xml file but we can't even address it because the name is random. This sucks.
// So we do a manual SET NULL|DEFAULT when userHome.remove() is called.
// @org.hibernate.annotations.ForeignKey(name = "FK_WIKI_NODE_CREATED_BY_USER_ID")
protected User createdBy;
Now all subclasses get that foreign key constraint name in the database catalog, which isn't possible - constraint names have to be unique.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-3339) Query cache stops working after object save
by Alex Oleynikov (JIRA)
Query cache stops working after object save
-------------------------------------------
Key: HHH-3339
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3339
Project: Hibernate3
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, MS SQL 2005 Database. Windows XP SP2
Reporter: Alex Oleynikov
It seems like HB Query cache stops working as soon as given object type is being saved (it does not matter if it was save to existing object or insert of new object instance).
The code looks like this. Where User is just a primitive POJO with couple of properties.
// #1
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// #2
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// insert new User object
user = new User();
user.setUserID((int)(Math.random() * Integer.MAX_VALUE));
user.setUserName("Ten");
session.beginTransaction();
session.save(user);
session.getTransaction().commit();
// #3
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
// #4
query = session.createQuery("from User where userID = :id");
query.setCacheable(true);
query.setParameter("id", 10);
user = (User) query.list().get(0);
>From MS SQL Profiler I can clearly see that no queries is executed for #2 (e.g. it hit the cache), but queries are executed for #3 and #4. From HB debug log I see following:
For #2 Query (cache is hit) - correct:
06:54:25,337 DEBUG StandardQueryCache:102 - checking cached query results in region: org.hibernate.cache.StandardQueryCache
06:54:25,337 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,337 DEBUG StandardQueryCache:117 - returning cached query results
During User insert:
06:54:25,368 DEBUG UpdateTimestampsCache:65 - Invalidating space [USERS], timestamp: 4967466866147328
For #3 Query:
06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888
06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date
For #4 Query (or any subsequent query for this matter):
06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS]
06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888
06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date
Please note the timestamp numbers for #4 query - even though I would expect query to be re-cached in #3, it still shows old timestamp. So I may think that when re-caching a query it does not update cache entry timestamp which is not up-to-date due to save().
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-3407) @TableGenerator does not increment pkColumnValue by allocationSize
by Dan Ciarniello (JIRA)
@TableGenerator does not increment pkColumnValue by allocationSize
------------------------------------------------------------------
Key: HHH-3407
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3407
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6, 3.2.4
Environment: JBoss 4.2.3, RHEL4, JDK1.5
Reporter: Dan Ciarniello
According to the JPA, the allocationSize attribute to @TableGenerator is "The amount to increment by when allocating id numbers from the generator" but the value is actually incremented by 1 regardless of allocationSize. The id is generated properly apparently according to the formula
id = lastkeyval*allocationSize + i where 0<i<allocationSize
The problems with this algorithm are:
1. One cannot tell what the next key value range is from the key table without knowing the allocationSize (minor)
2. If the allocationSize is reduced, already existing key values will be generated (major)
3. If two applications are configured with different allocation sizes, there will be an overlap in generated values (major)
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2131) SYBASE +select for update is showing deadlock because lock is not working properly
by George Thomas (JIRA)
SYBASE +select for update is showing deadlock because lock is not working properly
----------------------------------------------------------------------------------
Key: HHH-2131
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2131
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: sybaseASE 12.5.03 in solaris +hibernate3.1.3
Reporter: George Thomas
I am connecting to Sybase database from hibernate.I tried setting locks using while selecting rows
1.session.load(class,id,LOCKMODE.UPGRADE)
2.session.lock(obj,LOCKMODE.UPGRADE)
I am attaching a sample code while updating a field in table fund after selecting it.
{
Fund fund = null;
ClientCredential credential = new ClientCredential("testDatabase", fund);
org.hibernate.Session session = SessionFactoryManager.getSessionFactory(credential).getCurrentSession();
Transaction transaction = session.beginTransaction();
log.info("Run by " + Thread.currentThread().getName());
fund = (Fund) session.get(Fund.class, new Short((short)12), LockMode.UPGRADE);
fund.setLegalEntityOrgId(fund.getLegalEntityOrgId()+1);
transaction.commit();
}
my requirement was that i wanted to do a select for update.I should acquire lock on certain rows and do a matching and if concurrent request comes ,it should wait till transaction is over that is lock is released.
When I went through the hibernate code,the hibernate is making static queries in the beginning while loading session factory.Since we are appending the holdlock during execution,the sybase dialect is not appending.
As a work around I tested with native sql with holdlock but when I test concurrent request using threads its bombing.Its throwing LockAcquisitionException.( Your server command (family id #0, process id #3777) encountered a deadlock situation.).can anyone give a solution to this problem???
org.hibernate.exception.LockAcquisitionException: could not update: [com.citco.aexeo.common.dataaccess.domain.Fund#12]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:84)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2223)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2375)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:91)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:233)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:107)
at com.satyam.Testing.doTransaction(Testing.java:103)
at com.satyam.MyRunnable.run(MyRunnable.java:13)
at java.lang.Thread.run(Thread.java:568)
Caused by: com.sybase.jdbc2.jdbc.SybSQLException: Your server command (family id #0, process id #3777) encountered a deadlock situation. Please re-run your command.
at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2636)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1996)
at com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:204)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:187)
at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1642)
at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1625)
at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate(SybPreparedStatement.java:91)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:23)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2205)
... 14 more
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2691) Insert Into Select command outputs incorrect exception
by John Aylward (JIRA)
Insert Into Select command outputs incorrect exception
------------------------------------------------------
Key: HHH-2691
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2691
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4.sp1 with Annotations 3.3.0 And Validator 3.0.0
MySQL 5.0.42
Reporter: John Aylward
receive following exception:
org.hibernate.QueryException: number of select types did not match those for insert [INSERT INTO ProviderInvoiceLineItem (amount,billingAccount,circuit,description,invoice,type) SELECT pili.amount,pili.billingAccount,pili.circuit,pili.description,:newInvoice,pili.type) FROM com.cicat.bedrock.billing.model.ProviderInvoiceLineItem pili WHERE pili.invoice = :oldInvoice]
exception should be that token ')' is not excepected near "pili.type"
Should not have gotten as far as it did, should have blown up on parsing the HQL
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2374) setFetchMode() ignore incorect path
by Baptiste MATHUS (JIRA)
setFetchMode() ignore incorect path
-----------------------------------
Key: HHH-2374
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2374
Project: Hibernate3
Type: Bug
Versions: 3.2.0.ga
Environment: All DB I guess
Reporter: Baptiste MATHUS
This bug report is in fact a copy of the one that was already present in H2 : http://opensource.atlassian.com/projects/hibernate/browse/HB-763 . It does not seem to have changed in H3.
When calling setFetchMode("path", FetchMode.JOIN) on a criteria, even if the path is not correct, Hibernate does not complain. Its behaviour seems to be to simply ignore this bad path. I guess this should throw an exception. In fact, the bad thing of ignoring bad path is that if the developer was wrong specifying the path (typo, for example), then the join simply won't happen :-/.
I wrote a very simple testcase :
public void testFindClients()
{
Session session = HibernateUtil.currentSession();
session.beginTransaction();
Client c = (Client)session.createCriteria(Client.class).setFetchMode("foo", FetchMode.JOIN)
.setFetchMode("foo.bar", FetchMode.JOIN).uniqueResult();
session.getTransaction().commit();
}
My Client class has some relationships with other classes, but obviously none named "foo". The code above just issue the following select :
select
this_.ID as ID0_0_,
this_.nom as nom0_0_,
this_.prenom as prenom0_0_,
this_.age as age0_0_
from
Client this_
Thanks again for your great work, guys!
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2344) Persistent collection queued operation ignored with lazy inverse one-to-many collection.
by Sebastien Robert (JIRA)
Persistent collection queued operation ignored with lazy inverse one-to-many collection.
----------------------------------------------------------------------------------------
Key: HHH-2344
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2344
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1
Reporter: Sebastien Robert
I load an Object that contains a lazy inverse collection (one-to-many).
Hibernate wrap my collection with a PersistentMap
There is objects in the collection in the database but in my case the PersistentMap is not yet initialized.
I perform a remove operation on the persistentMap with a known key of one of the objects.
The map is not initialized (and the relation is an inverse one-to-many) so the map queue the removeOperation.
I perform a get operation with the same key and the value is still returned.
If we look closer at what happened in the PersistentMap, it's look like this.
//*****
public Object remove(Object key) {
if ( isPutQueueEnabled() ) { // This returned true, the
// map is not yet
// initialized
Object old = readElementByIndex( key ); // This method triggered
// an initialization of the
// map.
// Queued operation are
// processed in the after
// init method
queueOperation( new Remove( key, old ) ); // The remove operation
// is queued.
return old;
}
....
//*******
When i perform the get operation on the map the map is now initialized. The get is processed by the underlying map and the value is returned. The queued operation is completely ignored.
Currently i fixed my code by performing a containsKey before the remove . The containsKey initialize the map and then the remove do not queue the operation. But by looking at all the PersistentCollection it seem that i may have the same problem using put and remove with other persistentCollection.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-3627) String Scalar Function CONCAT and operator || in HQL not working correctly with numeric values
by Eric Belanger (JIRA)
String Scalar Function CONCAT and operator || in HQL not working correctly with numeric values
----------------------------------------------------------------------------------------------
Key: HHH-3627
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3627
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.3.1
Environment: MS SQL 2005
Reporter: Eric Belanger
Priority: Minor
Since HQL translate the CONCAT and || to + in SQL, numeric values get added together instead of being converted to String and concanated. Also causes problems when concatenating a numeric with a string.
SELECT CONCAT(1, 2) FROM...
Returns 3 instead of '12'
SELECT CONCAT('TWO', 2) FROM ...
java.sql.SQLException: Conversion failed when converting the varchar value 'TWO' to data type int.
java.sql.SQLException: Conversion failed when converting the varchar value 'TWO' to data type int.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224)
at net.sourceforge.jtds.jdbc.TdsCore.isDataInResultSet(TdsCore.java:792)
at net.sourceforge.jtds.jdbc.JtdsResultSet.<init>(JtdsResultSet.java:146)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:424)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatement.java:693)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
at org.hibernate.loader.Loader.doQuery(Loader.java:674)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.console.HQLQueryPage.getList(HQLQueryPage.java:50)
at org.hibernate.eclipse.console.views.QueryPageViewer$ContentProviderImpl.getElements(QueryPageViewer.java:114)
at org.eclipse.jface.viewers.StructuredViewer.getRawChildren(StructuredViewer.java:937)
at org.eclipse.jface.viewers.ColumnViewer.getRawChildren(ColumnViewer.java:693)
at org.eclipse.jface.viewers.AbstractTableViewer.getRawChildren(AbstractTableViewer.java:1071)
at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:871)
at org.eclipse.jface.viewers.StructuredViewer.getSortedChildren(StructuredViewer.java:994)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefreshAll(AbstractTableViewer.java:685)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:633)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:620)
at org.eclipse.jface.viewers.AbstractTableViewer$2.run(AbstractTableViewer.java:576)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330)
at org.eclipse.jface.viewers.AbstractTableViewer.inputChanged(AbstractTableViewer.java:574)
at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:251)
at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1606)
at org.hibernate.eclipse.console.views.QueryPageViewer.createTable(QueryPageViewer.java:218)
at org.hibernate.eclipse.console.views.QueryPageViewer.createControl(QueryPageViewer.java:197)
at org.hibernate.eclipse.console.views.QueryPageViewer.<init>(QueryPageViewer.java:154)
at org.hibernate.eclipse.console.views.QueryPageTabView.rebuild(QueryPageTabView.java:114)
at org.hibernate.eclipse.console.views.QueryPageTabView$1.contentsChanged(QueryPageTabView.java:78)
at org.hibernate.eclipse.console.views.QueryPageTabView$1.intervalAdded(QueryPageTabView.java:88)
at javax.swing.AbstractListModel.fireIntervalAdded(AbstractListModel.java:130)
at org.hibernate.console.QueryPageModel.add(QueryPageModel.java:67)
at org.hibernate.console.KnownConfigurations$1.queryPageCreated(KnownConfigurations.java:90)
at org.hibernate.console.ConsoleConfiguration.fireQueryPageCreated(ConsoleConfiguration.java:419)
at org.hibernate.console.ConsoleConfiguration.access$5(ConsoleConfiguration.java:415)
at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:391)
at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:65)
at org.hibernate.console.ConsoleConfiguration.executeHQLQuery(ConsoleConfiguration.java:383)
at org.hibernate.eclipse.hqleditor.HQLEditor.executeQuery(HQLEditor.java:406)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.execute(ExecuteQueryAction.java:72)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.run(ExecuteQueryAction.java:52)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.runWithEvent(ExecuteQueryAction.java:56)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:546)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490)
at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:443)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1101)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3319)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:169)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
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.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
--
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, 10 months