[Hibernate-JIRA] Created: (HHH-2022) ORA-00911: invalid character when field begins with underscore
by Jerry Cattell (JIRA)
ORA-00911: invalid character when field begins with underscore
--------------------------------------------------------------
Key: HHH-2022
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2022
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.0.5, 3.1.3, 3.2.0.cr3
Environment: Hibernate 3.1.3
Oracle 10.2.0.1
Reporter: Jerry Cattell
Priority: Minor
Attachments: InvalidCharacterErrorCase.java, SimpleObject.hbm.xml, SimpleObject.java
Hibernate is generating invalid SQL (for Oracle) for collections that are stored in fields with names that start with underscores.
In this SQL:
Hibernate: select _tags0_.SIMPLE_OBJECT_ID as SIMPLE1_0_, _tags0_.TAG as TAG0_ from SIMPLE_OBJECT_TAG _tags0_ where _tags0_.SIMPLE_OBJECT_ID=?
an alias called "_tags0_" is created for the collection table. Unfortunately, Oracle does not allow non-alphabetic characters for the first character in an alias.
Here's the stacktrace:
Hibernate: select _tags0_.SIMPLE_OBJECT_ID as SIMPLE1_0_, _tags0_.TAG as TAG0_ from SIMPLE_OBJECT_TAG _tags0_ where _tags0_.SIMPLE_OBJECT_ID=?
WARN JDBCExceptionReporter 20060822-011120.817 - SQL Error: 911, SQLState: 42000
ERROR JDBCExceptionReporter 20060822-011120.818 - ORA-00911: invalid character
INFO DefaultLoadEventListener 20060822-011120.820 - Error performing load command
org.hibernate.exception.SQLGrammarException: could not initialize a collection: [SimpleObject._tags#1]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1926)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:520)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1676)
at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:454)
at org.hibernate.engine.StatefulPersistenceContext.initializeNonLazyCollections(StatefulPersistenceContext.java:755)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:229)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:161)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:792)
at InvalidCharacterErrorCase.runTest(InvalidCharacterErrorCase.java:28)
at InvalidCharacterErrorCase.main(InvalidCharacterErrorCase.java:11)
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:585)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.sql.SQLException: ORA-00911: invalid character
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:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:799)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:839)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1132)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3329)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
at org.hibernate.loader.Loader.doQuery(Loader.java:662)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1919)
... 26 more
I have attached a test case that causes this error.
After a little bit of research, it appears that a change to StringHelper.generateAlias(String description, int unique) (or StringHelper.generateAliasRoot(String description)) to remove all characters up to the first alphabetic character would solve this 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
16 years, 10 months
[Hibernate-JIRA] Created: (HHH-2488) Resolution of filters' conditions should be postponed till all mappings are loaded.
by Dmitry Katsubo (JIRA)
Resolution of filters' conditions should be postponed till all mappings are loaded.
-----------------------------------------------------------------------------------
Key: HHH-2488
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2488
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate-Version: 3.2.2.ga
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Reporter: Dmitry Katsubo
When trying to use the possibility to define the conditions for the same filters in {{<filter-def>}}, the following exception occurs, as the resolution of conditions should be done at a later stage, after all mappings are loaded:
{noformat}
Exception in thread "main" java.lang.NullPointerException
at org.hibernate.cfg.HbmBinder.parseFilter(HbmBinder.java:2931)
at org.hibernate.cfg.HbmBinder.bindCollection(HbmBinder.java:1462)
at org.hibernate.cfg.HbmBinder$2.create(HbmBinder.java:2757)
{noformat}
The example of definition, that uses filters:
{code:xml|title=clauses.hbm.xml|borderStyle=solid}
<class name="ClauseFolderImpl" table="stc_folders">
<id name="id">
<generator class="native" />
</id>
<property name="name" not-null="true" />
<property name="private" not-null="true" />
<set name="subFolders" outer-join="false" cascade="none">
<key column="parentId" />
<one-to-many class="ClauseFolderImpl" />
<filter name="folderFilterLimited" />
<filter name="folderFilter" />
</set>
<filter name="folderFilterLimited" />
<filter name="folderFilter" />
</class>
<filter-def name="folderFilterLimited" condition="(parentId is null or (languageId = :languageId and procedureTypeId = :procedureTypeId))" >
<filter-param name="languageId" type="int" />
<filter-param name="procedureTypeId" type="int" />
</filter-def>
<filter-def name="folderFilter" condition="(parentId is null or private = :isPrivate)">
<filter-param name="isPrivate" type="boolean" />
</filter-def>
{code}
As Hibernate ues DTD to check the validity of configuration file, the {{<filter-def>}} definitions can't be moved to the beginning of the configuration file. The possible walkaround is to define filters in another file, and include it first:
{code:xml|title=hibernate-configuration.xml|borderStyle=solid}
<hibernate-configuration>
<session-factory>
...
<mapping resource="filters.hbm.xml"/> <!-- only filter-def's here -->
<mapping resource="clauses.hbm.xml"/>
...
</session-factory>
</hibernate-configuration>
{code}
Relative issue is [http://opensource.atlassian.com/projects/hibernate/browse/HHH-1182#action... HHH-1182].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 10 months
[Hibernate-JIRA] Created: (HHH-2189) Left Outer Join Conditions
by yann degat (JIRA)
Left Outer Join Conditions
--------------------------
Key: HHH-2189
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2189
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.1.3
Reporter: yann degat
Priority: Blocker
Attachments: OracleJoinFragment.java, OracleJoinFragment.java
the "org.hibernate.sql.OracleJoinFragment.addLeftOuterJoinCondition"
does not take the "!=" operator into account.
it places the "(+)" like this "!(+)=" instead of " (+) !="
( != is a valid operator for Oracle )
and it returns (+)<(+)> for the '<>' operator
here's a patch. (maybe not the best one )
/**
* This method is a bit of a hack, and assumes
* that the column on the "right" side of the
* join appears on the "left" side of the
* operator, which is extremely wierd if this
* was a normal join condition, but is natural
* for a filter.
*/
private void addLeftOuterJoinCondition(String on) {
StringBuffer buf = new StringBuffer( on );
for ( int i = 0; i < buf.length(); i++ ) {
char character = buf.charAt( i );
boolean isInsertPoint = OPERATORS.contains( new Character( character ) ) ||
( character == ' ' && buf.length() > i + 3 && "is ".equals( buf.substring( i + 1, i + 4 ) ) ) ;
if( character == '<' && buf.length() > i + 1 && ">".equals( buf.substring( i + 1, i + 2 ) ) ){
isInsertPoint = false;
buf.insert( i, "(+)" );
i += 3 + 2;
}
if ( isInsertPoint ) {
buf.insert( i, "(+)" );
i += 3;
}
if( character == '!' && buf.length() > i + 1 && "=".equals( buf.substring( i + 1, i + 2 ) ) ){
buf.insert( i, "(+)" );
i += 3 + 2;
}
}
addCondition( buf.toString() );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 10 months
[Hibernate-JIRA] Created: (HHH-2503) AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
by Dag Liodden (JIRA)
AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
-----------------------------------------------------------------------------
Key: HHH-2503
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2503
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.2, 3.2.3
Environment: 3.2.2GA and trunk
Reporter: Dag Liodden
Seems to be a small typo on line 3718 in AbstractEntityPersister (trunk and 3.2.2 GA) which makes exceptions during property generation being logged but not thrown:
catch( SQLException sqle ) {
JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
There should be a throw in there I guess. :)
catch( SQLException sqle ) {
throw JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
This bug will not be noticeable in most cases and is probably why it hasn't been detected / fixed so far. The method in question (processGeneratedProperties) is used for retrieving properties that are marked as "generated" in the mapping document / annotations - in other words any value that the database provides and is considered "read-only" from the Hibernate application's point of view.
The generated value is retrieved by an extra select statement executed by Hibernate after an entity has been inserterd and / or updated (according to how the generated property is flagged). In my particular case, a property (not a key) is marked as generated="insert", so after Hibernate inserts a new entity to the database, it will immediately do a select and set the generated property to the value the database returns.
Only in rare cases will this select fail in any way - in fact, I cannot think of any situations other than mapping errors (e.g getInt on a CHAR column) that can cause errors in this last select. That is in addition to my situation - a deadlock.
My entity class uses uuid.hex generator for the PK, but at one point, we introduced a second unique key due to purely aestethic reasons. This is a SQL Server identity column. Since we don't do any explicit table locking during the inserts, we end up with deadlocks every time the following happens:
T1: INSERT INTO TABLE (ID) values (?)
T2: INSERT INTO TABLE (ID) values (?)
T2: SELECT GENERATED_ID FROM TABLE WHERE ID = ? -- T1's insert hasn't been committed, so what should the the generated ID be? Deadlock!
T1: SELECT GENERATED_ID FROM TABLE WHERE ID = ?
...
SQL Server throws an error to indicate the deadlock, but due to the missing throw in the processGeneratedProperties-method, it is never shown to the process doing the insert. The generated property is not set and retains it's null (or 0 in case of a primitive) without the business logic ever knowing that the entity could not be saved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 10 months
[Hibernate-JIRA] Created: (HHH-2320) Regression: optional properties under a <join> tag no longer update properly
by Chris Jones (JIRA)
Regression: optional properties under a <join> tag no longer update properly
----------------------------------------------------------------------------
Key: HHH-2320
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2320
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.0.cr4, 3.2.0.ga, 3.2.0.cr5
Environment: hibernate 3.2.0.cr4 through 3.2.1.ga
hsql 1.8.0.7 and Oracle 9i
Reporter: Chris Jones
This was specifically introduced with the revision 10217 changes on the 3.2 branch in src/org/hibernate/persister/entity/AbstractEntityPersister.java
Given the following setup:
<class name="Thing">
<id .../>
<join table="JOIN_TABLE" optional="true">
<key column="THING_ID" not-null="true"/>
<property name="joinedProperty" column="JOINED_PROPERTY"/>
</join>
</class>
scenario:
Thing thing1 = new Thing();
thing1.setJoinedProperty("thing1");
save(thing1);
// a record in the JOIN_TABLE is created properly and updates on the property can occur
Thing thing2 = new Thing();
thing2.setJoinedProperty(null);
save(thing2);
// no record in JOIN_TABLE is created
thing2.setJoinedProperty("thing2");
save(thing2);
// in revision 10216, hibernate correctly runs an INSERT to create a JOIN_TABLE record with the value "thing2"
// in revision 10217, hibernate incorrectly runs an UPDATE to try and update a non-existant record in the JOIN_TABLE with the thing2 id
It looks like the expectation.verifyOutcome() method should be throwing a StaleStateException if the attempted update effects 0 rows.
I will try and get an official hibernate testcase going and possibly a patch, but I wanted to enter this now in case there is something I'm missing that makes this change in functionality intentional.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
16 years, 10 months