[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
17 years, 4 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
17 years, 4 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
17 years, 4 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
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2289) CLONE -Support new MySQL 5.0.12 join syntax
by Peter Lundberg (JIRA)
CLONE -Support new MySQL 5.0.12 join syntax
-------------------------------------------
Key: HHH-2289
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2289
Project: Hibernate3
Type: New Feature
Components: query-sql
Versions: 3.1.2
Reporter: Peter Lundberg
http://dev.mysql.com/doc/refman/5.0/en/join.html
"Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard. The following list provides more detail about several effects of the 5.0.12 change in join processing. The term "previously" means "prior to MySQL 5.0.12."
Using 5.0.18 and hibernate 3.1.2, hibernate is not producing the correct join syntax for the latest versions of mysql.
For example:
FROM tableA AS A, tableB AS B INNER JOIN tableC AS C ON A.field1 =
C.field2
The above fails, because the B JOIN C is evaluated before the A alias has
been created.
The solution is to use parentheses to force an order of evaluation:
FROM (tableA AS A, tableB AS B) INNER JOIN tableC AS C ON A.field1 =
C.field2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2164) Minor bug in section "20.1.1. Customizing the schema"
by Andres Gonzalez (JIRA)
Minor bug in section "20.1.1. Customizing the schema"
-----------------------------------------------------
Key: HHH-2164
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2164
Project: Hibernate3
Type: Bug
Components: documentation
Versions: 3.2.0.ga
Reporter: Andres Gonzalez
Where it says:
*******************************************************************************************************************************
A unique-key attribute may be used to group columns in a single unique key constraint. Currently, the specified value of the unique-key attribute is not used to name the constraint in the generated DDL, only to group the columns in the mapping file.
<many-to-one name="org" column="orgId" unique-key="OrgEmployeeId"/>
<property name="employeeId" unique-key="OrgEmployee"/>
*******************************************************************************************************************************
i think the unique-key attributes should jave both the same value ("OrgEmployee", for example)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 4 months