hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1796) TreeCache based providers and Fqn

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796?page=all ]
     
Steve Ebersole closed HHH-1796:
-------------------------------

    Resolution: Fixed

The basic pattern discussed with Manik is:

Fqn regionFqn = Fqn.fromString( regionName.replace( '.', '/' ) );
cache.put( new Fqn( regionFqn, key ), ITEM, value, option );



> TreeCache based providers and Fqn
> ---------------------------------
>
>          Key: HHH-1796
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Apparently we have not been using tree cache in the most proper manner in regards to Fqn construction.  The way in which we construct Fqns actually leads to a very flat tree structure.  For example consider a region for "org.hibernate.test.hql.Animal"; this actually leads to a tree node structured like:
> /org/hibernate/test/hql/Animal
>         /id1
>         /id2
>         /...
> Notice that the Hibernate region-name leads to a flat node which is a direct child of the root node...
> The issue is twofold:
> 1) This may be one of the causes of the high level of contention in the older pessimistic TreeCache model
> 2) This is currently causing problems with the optimistic locking stuff because the "parent" node is version-incremented whenever its children is mutated (child added/removed)

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1796) TreeCache based providers and Fqn

[Steve E. (JIRA) <no...@at...>]

TreeCache based providers and Fqn
---------------------------------

         Key: HHH-1796
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796
     Project: Hibernate3
        Type: Improvement

  Components: core  
    Reporter: Steve Ebersole
 Assigned to: Steve Ebersole 
     Fix For: 3.2.0


Apparently we have not been using tree cache in the most proper manner in regards to Fqn construction.  The way in which we construct Fqns actually leads to a very flat tree structure.  For example consider a region for "org.hibernate.test.hql.Animal"; this actually leads to a tree node structured like:
/org/hibernate/test/hql/Animal
        /id1
        /id2
        /...
Notice that the Hibernate region-name leads to a flat node which is a direct child of the root node...

The issue is twofold:
1) This may be one of the causes of the high level of contention in the older pessimistic TreeCache model
2) This is currently causing problems with the optimistic locking stuff because the "parent" node is version-incremented whenever its children is mutated (child added/removed)

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (ANN-353) Ability to mix @Entity and @Embeddable annotations on the same class

[Emmanuel B. (JIRA) <no...@at...>]

Ability to mix @Entity and @Embeddable annotations on the same class
--------------------------------------------------------------------

         Key: ANN-353
         URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-353
     Project: Hibernate Annotations
        Type: New Feature

  Components: binder  
    Reporter: Emmanuel Bernard




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1748) Setting a comment that contains a single quote on a query results in an unintuitive exception

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748?page=comments#action_23207 ] 

Max Rydahl Andersen commented on HHH-1748:
------------------------------------------

what i have done now is just to make sure it doesn't throw exceptions.

to parse it more intelligently is of course a future option. feel free to contribute it ;)

> Setting a comment that contains a single quote on a query results in an unintuitive exception 
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1748
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3
> Oracle 10i
> Java 1.4.2_08
> Centos 4
>     Reporter: Corey Puffalt
>      Fix For: 3.2.0

>
>
> I've been using the (relatively) new setComment() feature which I find very useful during development and testing.  However, I've stumbled across an error when setting a comment that contains a single quote .  
> For example:
> List parents = session.createQuery("...").setComment("get kitten's parents").list();
> results in the following exception:
> Caused by: java.util.NoSuchElementException
>         at java.util.StringTokenizer.nextToken(StringTokenizer.java:259)
>         at org.hibernate.pretty.Formatter.format(Formatter.java:112)
>         at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:355)
>         at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:346)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:422)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:661)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
>         at org.hibernate.loader.Loader.doList(Loader.java:2145)
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
>         at org.hibernate.loader.Loader.list(Loader.java:2024)
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
>         at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
>         at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at mypkdg.MyClass.mymethod(MyClass.java:964)
> To get this particular error you also have to have the hibernate.format_sql property set to true (as you might guess from examining this stacktrace closely).  While I don't have a problem with single quotes being prohibited in a comment if they can't be escaped I *do* have a problem with the exception above as it doesn't tell me what's wrong...  Looks like a bug in the parser to me...
> Astute readers may ask what happens if I turn off sql formatting (hibernate.format_sql=false).  In this case, I got an exception from the Oracle10i JDBC driver:
> 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.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:211)
>         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.doList(Loader.java:2145)
>         ... 43 more
> Note that you'll also have to have the hibernate.use_sql_comments property set to true to reproduce this one.
> I guess there are two ways of fixing this problem:
> a) Explicitly prohibit "bad" characters like the single quote in comments and throw an appropriate exception.
> b) Handle single quotes properly in the org.hibernate.pretty.Formatter and also escape such characters (if possible) appropriately so they don't cause errors at the JDBC driver level.
> I assume this problem also affects comments set on Criterias and native SQL though I haven't verified 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1748) Setting a comment that contains a single quote on a query results in an unintuitive exception

[Corey P. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748?page=comments#action_23206 ] 

Corey Puffalt commented on HHH-1748:
------------------------------------

One further question: do you intend to fix this bug properly later on so that people like me that use single quotes in their comments can still expect their sql to be formatted nicely?

> Setting a comment that contains a single quote on a query results in an unintuitive exception 
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1748
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3
> Oracle 10i
> Java 1.4.2_08
> Centos 4
>     Reporter: Corey Puffalt
>      Fix For: 3.2.0

>
>
> I've been using the (relatively) new setComment() feature which I find very useful during development and testing.  However, I've stumbled across an error when setting a comment that contains a single quote .  
> For example:
> List parents = session.createQuery("...").setComment("get kitten's parents").list();
> results in the following exception:
> Caused by: java.util.NoSuchElementException
>         at java.util.StringTokenizer.nextToken(StringTokenizer.java:259)
>         at org.hibernate.pretty.Formatter.format(Formatter.java:112)
>         at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:355)
>         at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:346)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:422)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:661)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
>         at org.hibernate.loader.Loader.doList(Loader.java:2145)
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
>         at org.hibernate.loader.Loader.list(Loader.java:2024)
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
>         at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
>         at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at mypkdg.MyClass.mymethod(MyClass.java:964)
> To get this particular error you also have to have the hibernate.format_sql property set to true (as you might guess from examining this stacktrace closely).  While I don't have a problem with single quotes being prohibited in a comment if they can't be escaped I *do* have a problem with the exception above as it doesn't tell me what's wrong...  Looks like a bug in the parser to me...
> Astute readers may ask what happens if I turn off sql formatting (hibernate.format_sql=false).  In this case, I got an exception from the Oracle10i JDBC driver:
> 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.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:211)
>         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.doList(Loader.java:2145)
>         ... 43 more
> Note that you'll also have to have the hibernate.use_sql_comments property set to true to reproduce this one.
> I guess there are two ways of fixing this problem:
> a) Explicitly prohibit "bad" characters like the single quote in comments and throw an appropriate exception.
> b) Handle single quotes properly in the org.hibernate.pretty.Formatter and also escape such characters (if possible) appropriately so they don't cause errors at the JDBC driver level.
> I assume this problem also affects comments set on Criterias and native SQL though I haven't verified 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-669) Code level HQL query validation

[Emmanuel B. (JIRA) <no...@at...>]

Code level HQL query validation
-------------------------------

         Key: HBX-669
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-669
     Project: Hibernate Tools
        Type: New Feature

  Components: eclipse  
    Reporter: Emmanuel Bernard


When an Hibernate configuration is provided, the IDE should be able to validate a given HQL query written in the code and in the XML files
The code level warning would be a killer feature.

Note that the hard part for the code is to "reckognize" a string as HQL query.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (EJB-188) @PostUpdate can be called even if @PreUpdate is not when object is in DELETED state

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-188?page=all ]
     
Emmanuel Bernard resolved EJB-188:
----------------------------------

    Resolution: Fixed

> @PostUpdate can be called even if @PreUpdate is not when object is in DELETED state
> -----------------------------------------------------------------------------------
>
>          Key: EJB-188
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-188
>      Project: Hibernate Entity Manager
>         Type: Bug

>   Components: EntityManager
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (EJB-188) @PostUpdate can be called even if @PreUpdate is not when object is in DELETED state

[Emmanuel B. (JIRA) <no...@at...>]

@PostUpdate can be called even if @PreUpdate is not when object is in DELETED state
-----------------------------------------------------------------------------------

         Key: EJB-188
         URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-188
     Project: Hibernate Entity Manager
        Type: Bug

  Components: EntityManager  
    Reporter: Emmanuel Bernard
 Assigned to: Emmanuel Bernard 
     Fix For: 3.2.0




-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=all ]

Steve Ebersole updated HHH-1786:
--------------------------------

    type: Improvement  (was: Bug)

Ah great.  More WebSphere transaction crappiness! ;)

This is certainly not a Hibernate bug.  What we do is completely correct from the JTA/JTS specification perspective.  This is a problem in WebSphere because of their decision to not allow proper access to the JTA/JTS objects.  

As discussed many times before, they are technically allowed to not expose these objects if they so wish as the previous ad current J2EE specs have not required them to for compliance.  Even if every other app server in the world does this, it is IBM's decision whether or not to expose the JTA/JTS objects or some proprietary/vendor-lockin replicas.  Oh they'll argue that it is to "protect users from themselves", yet turn around and expose the same basic functionality, just through proprietary APIs ;)

In fact, JEE 5 will in all likelihood begin requiring access to a new javax.transaction.TransactionSynchronizationRegistry interface which is being proposed as part of the JTA 1.1 spec.  Of course we'll see how IBM circumvents that one in about 5 years when they are JEE 5 certified :))

I'll get around to looking at this when I get some time.  Or you could of course let IBM know how you feel about this decision they have made.  We'll see which comes to fruition first ;)

In the meantime, just plugin your implementation as the context to use (hibernate.current_session_context_class).  This is an extension point...

> JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
> ------------------------------------------------------------------------------
>
>          Key: HHH-1786
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786
>      Project: Hibernate3
>         Type: Improvement

>     Versions: 3.1.2
>  Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24
>     Reporter: Tomi Szabo
>  Attachments: JTASessionContext.java
>
>
> We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext.
> Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map.
> Possible patch is in attachements.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (EJB-186) Set the default cache provider to NoCache to prevent PU misuse to raise exceptions

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-186?page=all ]
     
Steve Ebersole closed EJB-186:
------------------------------

    Resolution: Fixed

done in core

> Set the default cache provider to NoCache to prevent PU misuse to raise exceptions
> ----------------------------------------------------------------------------------
>
>          Key: EJB-186
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-186
>      Project: Hibernate Entity Manager
>         Type: Improvement

>   Components: EntityManager
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0

>
>


-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1791) property update="false" ignored since 3.2.0.cr2

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1791?page=all ]
     
Steve Ebersole resolved HHH-1791:
---------------------------------

    Fix Version: 3.2.0
     Resolution: Fixed
      Assign To: Steve Ebersole

Yes, the binder code was messed up for this combination of options (generated="insert" and update="false"); the generated="insert" caused update="false" to be overriden as update="true"

> property update="false" ignored since 3.2.0.cr2
> -----------------------------------------------
>
>          Key: HHH-1791
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1791
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Hibernate 3.2.0.cr2, MS SQL Server 2000, jTDS
>     Reporter: Thomas Boerkel
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Mapping:
>   <class name="p2plus.AuftragPos" table="AUFTRAGPOS">
>     <cache usage="read-write"/>
>     
>     <composite-id>
>         <key-property name="auftrag" access="field"/>
>         <key-property name="position" access="field"/>
>     </composite-id>
>     <version name="timestamp" type="byte[]" generated="always" access="field"/>
>     <property name="id" access="field" generated="insert" update="false" insert="false"/>
>     <property name="artikel" access="field"/>
>     <property name="preis" access="field"/>
>     <property name="datum" access="field"/>
>   </class>
> I fetch an object, change a property and save. 
> Hibernate 3.2.0.cr1 executes:
> update AUFTRAGPOS set artikel=?, preis=?, datum=? where auftrag=? and position=? and timestamp=?
> Hibernate 3.2.0.cr2 executes:
> update AUFTRAGPOS set id=?, artikel=?, preis=?, datum=? where auftrag=? and position=? and timestamp=?
> Code:
>       Session session = HibernateUtil.getSessionFactory().getCurrentSession();
>       session.beginTransaction();
>       
>       AuftragPos auftragPos = new AuftragPos();
>       auftragPos.setAuftrag("4711");
>       auftragPos.setPosition((short)3);
>       auftragPos.setArtikel("V-10000");
>       auftragPos.setPreis(45);
>       auftragPos.setDatum(new Date());
>       session.save(auftragPos);
>       
>       auftragPos = (AuftragPos)session.createQuery("from AuftragPos where position=3").uniqueResult();
>       auftragPos.setPreis(78);
>       session.save(auftragPos);
>       
>       session.getTransaction().commit();

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1740) Build-time instrumentation breaks lazy="proxy"

[Frank G. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1740?page=comments#action_23202 ] 

Frank Grimes commented on HHH-1740:
-----------------------------------

Sorry, been kinda hectic around here and we reverted back to hibernate-3.1.2 a few weeks ago upon encountering this issue. (we resigned ourselves  to living with HHH-1435 for our upcoming releases)

I will try to find time to put a test case together by the end of the week.

> Build-time instrumentation breaks lazy="proxy"
> ----------------------------------------------
>
>          Key: HHH-1740
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1740
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3, 3.2.0 cr1, 3.2.0.cr2
>     Reporter: Frank Grimes
>     Priority: Critical

>
>
> I have a mapping that contains a many-to-one lazy="proxy".
> This alone works fine: I see $$EnhancerByCGLIB$$ as the type when I do a load
> Once I add a lazy property to the mapping and do build-time cglib enhancement, it breaks.
> Not only is the lazy property listed in $CGLIB_READ_WRITE_CALLBACK, but also my lazy="proxy" association. (i.e. no more proxy object)
> This works fine in hibernate-3.1.2.
> This was originally brought up here: http://forums.hibernate.org/viewtopic.php?t=958881
> Please let me know if more info or a test case is needed.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1748) Setting a comment that contains a single quote on a query results in an unintuitive exception

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748?page=comments#action_23201 ] 

Max Rydahl Andersen commented on HHH-1748:
------------------------------------------

don't blame hibernate for the oracle driver/db to be buggy ;)



> Setting a comment that contains a single quote on a query results in an unintuitive exception 
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1748
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3
> Oracle 10i
> Java 1.4.2_08
> Centos 4
>     Reporter: Corey Puffalt
>      Fix For: 3.2.0

>
>
> I've been using the (relatively) new setComment() feature which I find very useful during development and testing.  However, I've stumbled across an error when setting a comment that contains a single quote .  
> For example:
> List parents = session.createQuery("...").setComment("get kitten's parents").list();
> results in the following exception:
> Caused by: java.util.NoSuchElementException
>         at java.util.StringTokenizer.nextToken(StringTokenizer.java:259)
>         at org.hibernate.pretty.Formatter.format(Formatter.java:112)
>         at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:355)
>         at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:346)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:422)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:661)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
>         at org.hibernate.loader.Loader.doList(Loader.java:2145)
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
>         at org.hibernate.loader.Loader.list(Loader.java:2024)
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
>         at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
>         at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at mypkdg.MyClass.mymethod(MyClass.java:964)
> To get this particular error you also have to have the hibernate.format_sql property set to true (as you might guess from examining this stacktrace closely).  While I don't have a problem with single quotes being prohibited in a comment if they can't be escaped I *do* have a problem with the exception above as it doesn't tell me what's wrong...  Looks like a bug in the parser to me...
> Astute readers may ask what happens if I turn off sql formatting (hibernate.format_sql=false).  In this case, I got an exception from the Oracle10i JDBC driver:
> 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.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:211)
>         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.doList(Loader.java:2145)
>         ... 43 more
> Note that you'll also have to have the hibernate.use_sql_comments property set to true to reproduce this one.
> I guess there are two ways of fixing this problem:
> a) Explicitly prohibit "bad" characters like the single quote in comments and throw an appropriate exception.
> b) Handle single quotes properly in the org.hibernate.pretty.Formatter and also escape such characters (if possible) appropriately so they don't cause errors at the JDBC driver level.
> I assume this problem also affects comments set on Criterias and native SQL though I haven't verified 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1748) Setting a comment that contains a single quote on a query results in an unintuitive exception

[Corey P. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748?page=comments#action_23200 ] 

Corey Puffalt commented on HHH-1748:
------------------------------------

What about the second problem whereby a SQLException is triggered at the JDBC driver level?  

> Setting a comment that contains a single quote on a query results in an unintuitive exception 
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1748
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3
> Oracle 10i
> Java 1.4.2_08
> Centos 4
>     Reporter: Corey Puffalt
>      Fix For: 3.2.0

>
>
> I've been using the (relatively) new setComment() feature which I find very useful during development and testing.  However, I've stumbled across an error when setting a comment that contains a single quote .  
> For example:
> List parents = session.createQuery("...").setComment("get kitten's parents").list();
> results in the following exception:
> Caused by: java.util.NoSuchElementException
>         at java.util.StringTokenizer.nextToken(StringTokenizer.java:259)
>         at org.hibernate.pretty.Formatter.format(Formatter.java:112)
>         at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:355)
>         at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:346)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:422)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:661)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
>         at org.hibernate.loader.Loader.doList(Loader.java:2145)
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
>         at org.hibernate.loader.Loader.list(Loader.java:2024)
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
>         at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
>         at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at mypkdg.MyClass.mymethod(MyClass.java:964)
> To get this particular error you also have to have the hibernate.format_sql property set to true (as you might guess from examining this stacktrace closely).  While I don't have a problem with single quotes being prohibited in a comment if they can't be escaped I *do* have a problem with the exception above as it doesn't tell me what's wrong...  Looks like a bug in the parser to me...
> Astute readers may ask what happens if I turn off sql formatting (hibernate.format_sql=false).  In this case, I got an exception from the Oracle10i JDBC driver:
> 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.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:211)
>         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.doList(Loader.java:2145)
>         ... 43 more
> Note that you'll also have to have the hibernate.use_sql_comments property set to true to reproduce this one.
> I guess there are two ways of fixing this problem:
> a) Explicitly prohibit "bad" characters like the single quote in comments and throw an appropriate exception.
> b) Handle single quotes properly in the org.hibernate.pretty.Formatter and also escape such characters (if possible) appropriately so they don't cause errors at the JDBC driver level.
> I assume this problem also affects comments set on Criterias and native SQL though I haven't verified 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1795) default cache provider to NoCacheProvider

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1795?page=all ]
     
Steve Ebersole closed HHH-1795:
-------------------------------

    Resolution: Fixed

> default cache provider to NoCacheProvider
> -----------------------------------------
>
>          Key: HHH-1795
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1795
>      Project: Hibernate3
>         Type: Improvement

>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache.  Instead, default to NoCacheProvider.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1795) default cache provider to NoCacheProvider

[Steve E. (JIRA) <no...@at...>]

default cache provider to NoCacheProvider
-----------------------------------------

         Key: HHH-1795
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1795
     Project: Hibernate3
        Type: Improvement

    Reporter: Steve Ebersole
 Assigned to: Steve Ebersole 
     Fix For: 3.2.0


Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache.  Instead, default to NoCacheProvider.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1748) Setting a comment that contains a single quote on a query results in an unintuitive exception

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748?page=all ]
     
Max Rydahl Andersen closed HHH-1748:
------------------------------------

    Fix Version: 3.2.0
     Resolution: Fixed

verified, the formatter expected that quotes were paired.
Fixed by simply not triggering the exception - thus formatting will stop at the point of the quote. Not optimal but at least it does not throw exceptions.

> Setting a comment that contains a single quote on a query results in an unintuitive exception 
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1748
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1748
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3
> Oracle 10i
> Java 1.4.2_08
> Centos 4
>     Reporter: Corey Puffalt
>      Fix For: 3.2.0

>
>
> I've been using the (relatively) new setComment() feature which I find very useful during development and testing.  However, I've stumbled across an error when setting a comment that contains a single quote .  
> For example:
> List parents = session.createQuery("...").setComment("get kitten's parents").list();
> results in the following exception:
> Caused by: java.util.NoSuchElementException
>         at java.util.StringTokenizer.nextToken(StringTokenizer.java:259)
>         at org.hibernate.pretty.Formatter.format(Formatter.java:112)
>         at org.hibernate.jdbc.AbstractBatcher.format(AbstractBatcher.java:355)
>         at org.hibernate.jdbc.AbstractBatcher.log(AbstractBatcher.java:346)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:422)
>         at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
>         at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
>         at org.hibernate.loader.Loader.doQuery(Loader.java:661)
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
>         at org.hibernate.loader.Loader.doList(Loader.java:2145)
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
>         at org.hibernate.loader.Loader.list(Loader.java:2024)
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
>         at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
>         at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at mypkdg.MyClass.mymethod(MyClass.java:964)
> To get this particular error you also have to have the hibernate.format_sql property set to true (as you might guess from examining this stacktrace closely).  While I don't have a problem with single quotes being prohibited in a comment if they can't be escaped I *do* have a problem with the exception above as it doesn't tell me what's wrong...  Looks like a bug in the parser to me...
> Astute readers may ask what happens if I turn off sql formatting (hibernate.format_sql=false).  In this case, I got an exception from the Oracle10i JDBC driver:
> 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.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:211)
>         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.doList(Loader.java:2145)
>         ... 43 more
> Note that you'll also have to have the hibernate.use_sql_comments property set to true to reproduce this one.
> I guess there are two ways of fixing this problem:
> a) Explicitly prohibit "bad" characters like the single quote in comments and throw an appropriate exception.
> b) Handle single quotes properly in the org.hibernate.pretty.Formatter and also escape such characters (if possible) appropriately so they don't cause errors at the JDBC driver level.
> I assume this problem also affects comments set on Criterias and native SQL though I haven't verified 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1794) HQL query (list) that SELECTs instances mixed with scalars returns NULLs (instance mappings are in a one-to-one relation)

[Conor T. (JIRA) <no...@at...>]

HQL query (list) that SELECTs instances mixed with scalars returns NULLs (instance mappings are in a one-to-one relation) 
--------------------------------------------------------------------------------------------------------------------------

         Key: HHH-1794
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1794
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3
Postgres 8.1.2
Java 1.5.0_06

    Reporter: Conor Tee
 Attachments: hibernate-scalar-problem.tar.gz

Given that "a" is a table whose id is reflected in table "b" as a PRIMARY FOREIGN KEY.
Mapping a->b and b->a with the appropriate "one-to-one" mappings (I hope), then

"select a, b from A a join a.b b"

returns "a" and "b" instances correctly..

However: (this is where I see the problem)

"select a, b, 'Some scalar' from A a join a.b b" or "select a, a.B, 'Some scalar' from A a"
returns "a" and the "scalar" correctly, but returns NULL for b!

Attached is a working example with a README, Postgres schema build script and ant "build & run" script



-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1793) sequence class in <generate>

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1793?page=all ]
     
Max Rydahl Andersen closed HHH-1793:
------------------------------------

    Resolution: Incomplete

not enough information

> sequence class in <generate>
> ----------------------------
>
>          Key: HHH-1793
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1793
>      Project: Hibernate3
>         Type: Bug

>     Reporter: Jollson Sam Varghese

>
>
> Sequence class in generate is throwing error "could not instantiate id generator".

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1793) sequence class in <generate>

[Jollson S. V. (JIRA) <no...@at...>]

sequence class in <generate>
----------------------------

         Key: HHH-1793
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1793
     Project: Hibernate3
        Type: Bug

    Reporter: Jollson Sam Varghese


Sequence class in generate is throwing error "could not instantiate id generator".

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1792) Callable update/insert/delete statements should not force rowcount out parameter

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23197 ] 

Max Rydahl Andersen commented on HHH-1792:
------------------------------------------

Why do you want to keep the option ? The old way was broken. Did you use it ?

the leading ? = is oracle stuff and not relevant in respect to delete/insert/update since they do not return anything (except this currently non used out paramater at index 1)


> Callable update/insert/delete statements should not force rowcount out parameter
> --------------------------------------------------------------------------------
>
>          Key: HHH-1792
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792
>      Project: Hibernate3
>         Type: Deprecation

>   Components: core
>     Versions: 3.1.3, 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>     Priority: Blocker
>      Fix For: 3.2.0

>
>
> the current handling of <sql-insert>, <sql-update>, <sql-delete> when callable="true" is broken.
> It "forcefully" requires users to have an out parameter at the first position that returns the rowcount and then simply ignores it!
> This only became obvious when trying to use the sql-update on DB2 where executeUpdate returns -1 opposed to what is done
> on Oracle and MS SQL Server.
> We need to fix this by either:
> a) actually start using this value (which requires the SP to return an expected value which in most cases just will be 1 or 0)
> b) remove the need for this parameter and simply let the SP handle the error handling 
> I vote for B even though it will break backwards compability, since if they were using the old way they would either have failed on every operation (if running on DB2) or having the code silently ignore any possible update/delete rowcount mismatches.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

[Steve B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1725?page=comments#action_23196 ] 

Steve Baker commented on HHH-1725:
----------------------------------

I've been bitten by this too. I have a post update event listener which triggers my own lucene indexing.  This indexing does a deep traversal of the entity children to collect any interesting text to index, however this causes an AssertionFailure as described above.

If I only do a shallow indexing then there is no problem but then I have an incomplete lucene index, which is not ideal.

If this is not going to be fixed then what could be an appropriate workaround?  I'm thinking of having an indexing thread which waits for notification from the post update event listener.

> lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility
> --------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1725
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1725
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Tomasz Bech

>
>
> It is realted to anomaly: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1540
> 'When using custom event listeners, sometimes you mess with (and initialize) lazy collections by mistake, which causes CollectionEntry.postFlush(PersistentCollection) to throw an AssertionFailure'
> It is questionable why AT ALL exception is raised in this case!
> What is the most important: EJB3 spec is not prohibiting to check/read/ object involved in the event, so current implementation is agains EJB3 spec.
> Events are often used for validation so it is quite probable that the lazy property (collection) has to be accessed - and when it is lazy and not initialized before the exception is raised. Why hibernate cannot treat it in nicer way and allow such actions. 
> One workaround is to not-use-lazy (very bad).
> Second workaround: in the code outside flush (not in event) pre-initialize all lazy properties (in fact simulation of 'not-lazy).

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1792) Callable update/insert/delete statements should not force rowcount out parameter

[Paul H. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23195 ] 

Paul Hicks commented on HHH-1792:
---------------------------------

It'd be best if the user had the option..  are you imagining that it will be possible for the user to do either of these, depending on his own preference?

Either:
    <sql-delete callable="true">{? = call stpDeleteThing(?)}</sql-delete>
Or:
    <sql-delete callable="true">{call stpDeleteThing(?)}</sql-delete>

If hibernate detected and allowed for the presence of the leading ?=, that would be ideal.


> Callable update/insert/delete statements should not force rowcount out parameter
> --------------------------------------------------------------------------------
>
>          Key: HHH-1792
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792
>      Project: Hibernate3
>         Type: Deprecation

>   Components: core
>     Versions: 3.1.3, 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>     Priority: Blocker
>      Fix For: 3.2.0

>
>
> the current handling of <sql-insert>, <sql-update>, <sql-delete> when callable="true" is broken.
> It "forcefully" requires users to have an out parameter at the first position that returns the rowcount and then simply ignores it!
> This only became obvious when trying to use the sql-update on DB2 where executeUpdate returns -1 opposed to what is done
> on Oracle and MS SQL Server.
> We need to fix this by either:
> a) actually start using this value (which requires the SP to return an expected value which in most cases just will be 1 or 0)
> b) remove the need for this parameter and simply let the SP handle the error handling 
> I vote for B even though it will break backwards compability, since if they were using the old way they would either have failed on every operation (if running on DB2) or having the code silently ignore any possible update/delete rowcount mismatches.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1792) Callable update/insert/delete statements should not force rowcount out parameter

[Max R. A. (JIRA) <no...@at...>]

Callable update/insert/delete statements should not force rowcount out parameter
--------------------------------------------------------------------------------

         Key: HHH-1792
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792
     Project: Hibernate3
        Type: Deprecation

  Components: core  
    Versions: 3.1.3, 3.2.0.cr2    
    Reporter: Max Rydahl Andersen
    Priority: Blocker
     Fix For: 3.2.0


the current handling of <sql-insert>, <sql-update>, <sql-delete> when callable="true" is broken.

It "forcefully" requires users to have an out parameter at the first position that returns the rowcount and then simply ignores it!

This only became obvious when trying to use the sql-update on DB2 where executeUpdate returns -1 opposed to what is done
on Oracle and MS SQL Server.

We need to fix this by either:

a) actually start using this value (which requires the SP to return an expected value which in most cases just will be 1 or 0)

b) remove the need for this parameter and simply let the SP handle the error handling 


I vote for B even though it will break backwards compability, since if they were using the old way they would either have failed on every operation (if running on DB2) or having the code silently ignore any possible update/delete rowcount mismatches.



-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-352) Incorrect database sceme created, when using multiple n:m relations between 2 entities

[Emmanuel B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-352?pag=
e=3Dcomments#action_23194 ]=20

Emmanuel Bernard commented on ANN-352:
--------------------------------------

The problem is that implementing something like that is not trivial and wil=
l ovscure the code even more. Not sure it worth it.

> Incorrect database sceme created, when using multiple n:m relations betwe=
en 2 entities
> -------------------------------------------------------------------------=
-------------
>
>          Key: ANN-352
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/A=
NN-352
>      Project: Hibernate Annotations
>         Type: Bug

>     Versions: 3.2.0.cr1
>  Environment: Linux, Java 1.5, Postgresql 8.0
>     Reporter: Erik Tews

>
>
> Hi
> I got 2 entities:
> @Entity
> public class UserBean implements Serializable {
> ....
> @ManyToMany
>     protected Set<LectureBean> getAdminLectures() {
> ....
> @ManyToMany
>     protected Set<LectureBean> getLectures() {
> .... }
> and on the other side
> @Entity=20
> public class LectureBean implements Serializable {
> @ManyToMany(mappedBy=3D"adminLectures", fetch=3DFetchType.LAZY, cascade=
=3DCascadeType.PERSIST)
> protected Set<UserBean> getAdminUsers() {
> @ManyToMany(mappedBy=3D"lectures", fetch=3DFetchType.LAZY, cascade=3DCasc=
adeType.PERSIST)
> protected Set<UserBean> getUsers() {
> ....
> }
> so there are 2 n:m relations between these entities. Hibernate generates =
the following table:
> adminusers_userid | adminlectures_lectureid | users_userid | lectures_lec=
tureid
> so it puts these 2 relations in one table but it adds foreign keys:
>     =C2=BBfk3fb6262a62053223=C2=AB FOREIGN KEY (adminlectures_lectureid) =
REFERENCES lecturebean(lectureid)
>     =C2=BBfk3fb6262a569b3581=C2=AB FOREIGN KEY (users_userid) REFERENCES =
userbean(userid)
>     =C2=BBfk3fb6262afb45c494=C2=AB FOREIGN KEY (lectures_lectureid) REFER=
ENCES lecturebean(lectureid)
>     =C2=BBfk3fb6262a66a3ba50=C2=AB FOREIGN KEY (adminusers_userid) REFERE=
NCES userbean(userid)
> This makes it impossible to put 2 entities in relation, because 2 of the =
4 columns will always be null.
> Adding differen column names for the join tables with @JoinTable works ar=
ound the problem.

--=20
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=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira