hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1731) configuration.setProperty("connection.url", newJdbcUrl) fails

[Per L. (JIRA) <no...@at...>]

configuration.setProperty("connection.url", newJdbcUrl) fails
-------------------------------------------------------------

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

  Components: core  
    Versions: 3.1.2    
 Environment: WinXP, Tomcat 5.5, MySQL 5, Hibernate 3.1.2
    Reporter: Per Lindberg
 Attachments: HibernateDatabase.java

It appears that, after

   Configuration configuration = new Configuration().configure(cfgFileName);

but before

   new SchemaExport(configuration).create(false,true);
   sessionFactory = configuration.buildSessionFactory()

the JDBC Connection URL can't be changed with

configuration.setProperty("connection.url", newJdbcUrl)

Trying to do so causes configuration.getProperty to return the new value,
but the SessionFactory gets confused and appears to use the old value.
I have the impression that configure(cfgFileName) sets the properties
of the Configuration in some "hard" way, so that later calls to setProperty
are mostly ignored (except that getProperty returns the new value).

The attached file attempts to do this, and fails.


-- 
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-1730) <sql-function>

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

<sql-function>
--------------

         Key: HHH-1730
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1730
     Project: Hibernate3
        Type: New Feature

  Components: core  
    Reporter: Max Rydahl Andersen
    Priority: Minor


Now that we have a SQLFunctionRegistry it should be trivial to add something like:

<sql-function name="myfunction" class="org.my.function.Function"/>

and possibly with dialect-scoping.



-- 
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-176) Generated link table contains non nullable ids

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

Generated link table contains non nullable ids
----------------------------------------------

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

  Components: EntityManager  
    Versions: 3.1.0.Beta8    
 Environment: Derby database.
Hibernate 3.2.0cr1 (cr2 could not work at all it seems)

    Reporter: Christof Ameye
    Priority: Blocker


I have an entity A containing two lists (@OneToMany) relations to two different entity types B3 and B23, but both of these entity types are derived from the same persistable entity type Bp1. So both entity types arrive in the same table for Bp1.

When automatically generating the tables (the persistence.xml property 'hibernate.hbm2ddl.auto' is set to 'create-drop').

It seems it creates a link table containing 3 columns with 'A_ID', 'B3_ID' and 'B23_ID'.

Persisting always fails:

One entry in the table contains always an entry in column A_ID, but in the other columns there is always only one filled in (should). But any insert always fails, because there is always one of the columns null, but the table definition does not allow nulls; (it contains a link either to entity of type B3 or to entity of type B23).

I suppose I hit a bug ?

Hibernate 3.2CR1 with the latests annotations and entity manager. Using a Derby database.


-- 
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

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

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

Tomasz Bech commented on HHH-1725:
----------------------------------

I think there is small issue with current implementation (a bug?).
Scenario is:
object A has reference to B (lazy), B has collection C.
when in preInsert a.getB().getAnyProperty() is called the flush is raising exception 'collection b.c was not processed by flush()'.
(it is not rising exception like 'property b was not processed by flush()' - so the problem is only when there is lazy property which has at least ONE collection).

The collection C isn't even accessed, used, etc. The exception is to avoid situation of usage/modififcation of collection, and it isn't the case.
So shouldn't following function :
CollectionEntry:
public void postFlush(PersistentCollection collection) throws HibernateException {
		if ( isIgnore() ) {
			ignore = false;
		}
		else if ( !isProcessed() ) {
			throw new AssertionFailure( "collection [" + collection.getRole() + "] was not processed by flush()" );
		}
		collection.setSnapshot(loadedKey, role, snapshot);
	}

check also if collection was initialized? Like this:

public void postFlush(PersistentCollection collection) throws HibernateException {
		if ( isIgnore() ) {
			ignore = false;
		}
		else if (collection.wasInitialized() && !isProcessed() ) {
			throw new AssertionFailure( "collection [" + collection.getRole() + "] was not processed by flush()" );
		}
		collection.setSnapshot(loadedKey, role, snapshot);
	}

In this case the real (currently prohibited by Hibernate) usage of collections in flush will be reported.


> 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-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

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

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

Tomasz Bech commented on HHH-1725:
----------------------------------

Full 'not-lazy' object graph is too tough for the PC farm even :)

The problem could appear ONLY when the objects will be modified and there are no side effects when only reading?
The most common case is reading the main object + lazy properties + collection for validation, no changes in the objects. So maybe it can be set up less strict and allow simple reading, by configuration parameter for example. What do you think?



> 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-1397) HQL insert into ... select ... statement problem due to lacking table aliases in select clause

[Matan (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1397?pa=
ge=3Dcomments#action_23049 ]=20

Matan commented on HHH-1397:
----------------------------

I have this problem as well with version 3.1.2.

There are no aliases created in the select portion of the insert statement =
and therefore i'm getting "xxx" column is ambigous errors:

This HQL:

        insert into
            NotifyRec (company, project, dateEntered, status)
        select
            distinct c, proj, now(), 0
        from
            Company c
            inner join c.companyPrefss p
            inner join p.companyPrefsRecCats cats
            inner join p.companyPrefsRecBudgets budget,
            Project proj
        where
            p.emailRecommendations =3D :email
            and cats.id in (:categories)
            and budget.budget in (:budgets)
            and c.provider =3D :provider
            and c.systemStatus in (:system_status)
            and proj.id =3D :project_id


Turns into:

    insert  into
        notify_rec
        ( company_id, project_id, date_entered, status ) select
            distinct company0_.company_id as col_0_0_,
            project5_.project_id as col_1_0_,
            now() as col_2_0_,
            0 as col_3_0_=20
        from
            company company0_=20
        inner join
            company_prefs companypre1_=20
                on company_id=3Dcompanypre1_.company_id=20
        inner join
            company_prefs_rec_cat companypre2_=20
                on company_prefs_id=3Dcompanypre2_.company_prefs_id=20
        inner join
            cat cat3_=20
                on companypre2_.cat_id=3Dcat3_.cat_id=20
        inner join
            company_prefs_rec_budget companypre4_=20
                on company_prefs_id=3Dcompanypre4_.company_prefs_id,
            project project5_=20
        where
            email_recommendations=3D?=20
            and (
                cat_id in (
                    ? , ? , ? , ? , ?
                )
            )=20
            and (
                budget in (
                    ?
                )
            )=20
            and provider=3D?=20
            and (
                system_status in (
                    ?
                )
            )=20
            and project_id=3D?

Notice that the select statement where clause has no table aliases....  get=
 an SQL exception because of it :(

Any news on when this will be fixed?

> HQL insert into ... select ... statement problem due to lacking table ali=
ases in select clause
> -------------------------------------------------------------------------=
---------------------
>
>          Key: HHH-1397
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/H=
HH-1397
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.1
>  Environment: 3.1.1., PostgresSQL
>     Reporter: Lukas Barton

>
>
> I have got problem with INSERT INTO ... SELECT ...
> As I have very complex table stucture and join many tables easy workaroun=
d is not possible :-(
> I have SQL like this:
> insert into IdfKlient (dotazID,tabulkaVSabloneID,obec,status,metaTypKlien=
ta,ulice,ic,psc,rc,jmeno,idKlient) select dotaz.id,sablonaMain.id,dtaklient=
.obec,dtaklient.status,dtaklient.metaTypKlienta,dtaklient.ulice,dtaklient.i=
c,dtaklient.psc,dtaklient.rc,dtaklient.jmeno,dtaklient.idKlient from DtaKli=
ent as dtaklient,Dotaz as dotaz,TabulkaVSablone as sablonaMain, HodnotaPara=
metruDotazuString parametr_0 where sablonaMain.id=3D:sablona_id and exists(=
from Sablona as sablona where dotaz.sablona=3Dsablona and sablona.hlavniTab=
ulka=3DsablonaMain and exists(from IdfDavka as davka where dotaz.davka=3Dda=
vka and davka.status=3D:status)) and parametr_0.dotaz=3Ddotaz and dtaklient=
.rc=3Dparametr_0.hodnota and exists (from Parametr as param where param=3Dp=
arametr_0.parametr)
> But hibernate translates it into this (see where at the and of statement =
- where idsablona=3Did and hlavnitabulka=3Didtabulkavsablone......):
> insert into idfklient ( dotaz_id, sablona_id, obec, status, metatypklient=
a_id, ulice, ic, psc, rc, jmeno, idklient ) select dotaz1_.id as col_0_0_, =
tabulkavsa2_.idtabulkavsablone as col_1_0_, dtaklient0_.obec as col_2_0_, d=
taklient0_.status as col_3_0_, dtaklient0_.metatypklienta_id as col_4_0_, d=
taklient0_.ulice as col_5_0_, dtaklient0_.ic as col_6_0_, dtaklient0_.psc a=
s col_7_0_, dtaklient0_.rc as col_8_0_, dtaklient0_.jmeno as col_9_0_, dtak=
lient0_.idklient as col_10_0_ from dtaklient dtaklient0_, dotaz dotaz1_, ta=
bulkavsablone tabulkavsa2_, hodnotaparametrudotazustring hodnotapar3_ inner=
 join hodnotaparametrudotazu hodnotapar3_1_ on hodnotapar3_.idhodnoty=3Dhod=
notapar3_1_.id where idtabulkavsablone=3D? and (exists (select sablona4_.id=
 from sablona sablona4_ where idsablona=3Did and hlavnitabulka=3Didtabulkav=
sablone and (exists (select idfdavka5_.ID from IDFDAVKA idfdavka5_ where id=
davky=3DID and STATUS=3D?)))) and iddotazu=3Did and rc=3Dhodnota and (exist=
s (select parametr6_.id from parametr parametr6_ where id=3Didparametru))
> I found similar error here: http://opensource2.atlassian.com/projects/hib=
ernate/browse/HHH-1349

--=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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1729) Oracle9Dialect LockMode.UPGRADE conflicts with setMaxResults

[Mark L. (JIRA) <no...@at...>]

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

Mark Lewis commented on HHH-1729:
---------------------------------

Typo correction: the Hibernate version is 3.1, not 1.1.

> Oracle9Dialect LockMode.UPGRADE conflicts with setMaxResults
> ------------------------------------------------------------
>
>          Key: HHH-1729
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1729
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.1
>  Environment: Hibernate 1.1, Oracle 10g release 2 (also tested with 10g release 1).
>     Reporter: Mark Lewis
>     Priority: Minor

>
>
> When executing a simple HQL select from in Oracle, attempting to specify LockMode.UPGRADE to generate a "for update" clause while specifying a setMaxResults(10)  causes an Oracle-00904: Invalid identifier exception.  The same query works fine with several other tested dialects.
> The reason is that the generated SQL refers to a column by its actual column name, instead of the column alias assigned to it.  Consider the following example:
> select * from ( select scheduleel0_.elementId as elementId22_ from ScheduleElement scheduleel0_ ) where rownum <= ? for update of scheduleel0_.elementId
> This should be "for update of elementId22_", because "scheduleel0_.elementId" can't be referenced at this scope in the SQL.
> I've dug through the code but I think the fix will require a more knowledge of Hibernate's guts than I've got.  The offending SQL is inserted in org.hibernate.sql.ForUpdateFragment.toFragmentString(), but the ForUpdateFragment class doesn't know what the column aliases are for each real column, so it would need some way of getting that information.
> The HQL which causes the problem is as follows:
> from ScheduleElement as element where element.runnable=true and element.scheduleHead=true
> (I don't think it matters, but ScheduleElement is the root of a class hierarchy defined using joined-subclass)
> It is executed using the following Java code:
> session.createQuery(seeAboveForTheQueryString)
> 				.setLockMode("element", LockMode.UPGRADE)
> 				.setMaxResults(10)
> 				.list();
> Here is the bad SQL created from the HQL:
> -- Selecting all columns and left joining on subclass tables omitted for brevity
> select * from ( select scheduleel0_.elementId as elementId22_ from ScheduleElement scheduleel0_ ) where rownum <= ? for update of scheduleel0_.elementId

-- 
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-1729) Oracle9Dialect LockMode.UPGRADE conflicts with setMaxResults

[Mark L. (JIRA) <no...@at...>]

Oracle9Dialect LockMode.UPGRADE conflicts with setMaxResults
------------------------------------------------------------

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

    Versions: 3.1    
 Environment: Hibernate 1.1, Oracle 10g release 2 (also tested with 10g release 1).
    Reporter: Mark Lewis
    Priority: Minor


When executing a simple HQL select from in Oracle, attempting to specify LockMode.UPGRADE to generate a "for update" clause while specifying a setMaxResults(10)  causes an Oracle-00904: Invalid identifier exception.  The same query works fine with several other tested dialects.

The reason is that the generated SQL refers to a column by its actual column name, instead of the column alias assigned to it.  Consider the following example:

select * from ( select scheduleel0_.elementId as elementId22_ from ScheduleElement scheduleel0_ ) where rownum <= ? for update of scheduleel0_.elementId

This should be "for update of elementId22_", because "scheduleel0_.elementId" can't be referenced at this scope in the SQL.

I've dug through the code but I think the fix will require a more knowledge of Hibernate's guts than I've got.  The offending SQL is inserted in org.hibernate.sql.ForUpdateFragment.toFragmentString(), but the ForUpdateFragment class doesn't know what the column aliases are for each real column, so it would need some way of getting that information.

The HQL which causes the problem is as follows:
from ScheduleElement as element where element.runnable=true and element.scheduleHead=true

(I don't think it matters, but ScheduleElement is the root of a class hierarchy defined using joined-subclass)

It is executed using the following Java code:

session.createQuery(seeAboveForTheQueryString)
				.setLockMode("element", LockMode.UPGRADE)
				.setMaxResults(10)
				.list();

Here is the bad SQL created from the HQL:

-- Selecting all columns and left joining on subclass tables omitted for brevity
select * from ( select scheduleel0_.elementId as elementId22_ from ScheduleElement scheduleel0_ ) where rownum <= ? for update of scheduleel0_.elementId

-- 
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-1727) Add a SQLFunctionRegistry

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

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

    Resolution: Fixed

Done. Currently only programmatically available.

Do the following to get pre-H3.2 behavior:

Configuration classicCfg = new Configuration(); 
classicCfg.addSqlFunction( "count", new ClassicCountFunction()); 
classicCfg.addSqlFunction( "avg", new ClassicAvgFunction()); 
classicCfg.addSqlFunction( "sum", new ClassicSumFunction()); 
sf = classicCfg.buildSessionFactory();

> Add a SQLFunctionRegistry 
> --------------------------
>
>          Key: HHH-1727
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1727
>      Project: Hibernate3
>         Type: New Feature

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>      Fix For: 3.2.0

>
>
> been a long standing wish for having better configurability/programmatic control over how functions are handled.
> We should introduce a SQLFunctionRegistry that can be used by the various components that need it - the cfg/sf can then control/override it independent of in cooperation with the Dialect.

-- 
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-1728) StatelessSession.replicate()

[Gavin K. (JIRA) <no...@at...>]

StatelessSession.replicate()
----------------------------

         Key: HHH-1728
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1728
     Project: Hibernate3
        Type: New Feature

  Components: core  
    Reporter: Gavin King
 Assigned to: Steve Ebersole 


The replicate() operation really belongs on StatelessSession, not so much on Session, if you think about the usecase.

-- 
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-1724) Critieria needs to be aligned with new aggreation type rules

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

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

Max Rydahl Andersen updated HHH-1724:
-------------------------------------

    Fix Version:     (was: 3.2.0)
        Version:     (was: 3.2.0.cr2)

> Critieria needs to be aligned with new aggreation type rules
> ------------------------------------------------------------
>
>          Key: HHH-1724
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Reporter: Max Rydahl Andersen
>     Assignee: Max Rydahl Andersen
>     Priority: Blocker

>
>
> Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is.....
> created as blocker to make sure we either document or fix it.

-- 
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] Reopened: (HHH-1724) Critieria needs to be aligned with new aggreation type rules

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

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


decided not to align to be able to provide option for backward compatibility for this release. 

Might revisit it later when criteria and hql translation gets more unified.

> Critieria needs to be aligned with new aggreation type rules
> ------------------------------------------------------------
>
>          Key: HHH-1724
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Reporter: Max Rydahl Andersen
>     Assignee: Max Rydahl Andersen
>     Priority: Blocker

>
>
> Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is.....
> created as blocker to make sure we either document or fix it.

-- 
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

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

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

Emmanuel Bernard commented on HHH-1725:
---------------------------------------

I can assure the spec authors knew it.

It requires to dirty check all objects apply the listeners, then potentially dirty check once again to see if the user hasn"t change things in the meanwhile (recursively) then dirty check again to apply the DML operations. On big PC this is inefficient

The exception is here cause the flush process is looping through a list of object / collections, if you change that list, things can become undefined.

> 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-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

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

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

Tomasz Bech commented on HHH-1725:
----------------------------------

Spec is not allowing it explicitly because the authors maybe didn't realized that somehow it can be prohibited in implementation (and in case of Hibernate it is only prohibited for lazy properties).

Can you describe more precise why it would be inefficient? 
First of all I don't understand the reason of the exception when collection is not processed - why there is an exception, what it means exactly and how it helps developers? We are thinking currently of commenting the exception, but we have no feeling how dangerous it could be.

And if reading lazy properties in event is prohibited why the exception is not thrown immidiately at the place when happens but at the end of flush (and finding 'wrong' call place is huge job)?

About inefficiency. As I wrote I see in fact one solution - full 'not-lazy' of whole object graph can only work - I cannot imagine more inefficient solution.

> 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] Created: (HHH-1727) Add a SQLFunctionRegistry

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

Add a SQLFunctionRegistry 
--------------------------

         Key: HHH-1727
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1727
     Project: Hibernate3
        Type: New Feature

  Components: core  
    Versions: 3.2.0.cr2    
    Reporter: Max Rydahl Andersen
     Fix For: 3.2.0


been a long standing wish for having better configurability/programmatic control over how functions are handled.

We should introduce a SQLFunctionRegistry that can be used by the various components that need it - the cfg/sf can then control/override it independent of in cooperation with the Dialect.

-- 
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-1724) Critieria needs to be aligned with new aggreation type rules

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

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

    Resolution: Fixed

aggregate projections's now look up function via the normal sqlfunction lookup mechanism.

> Critieria needs to be aligned with new aggreation type rules
> ------------------------------------------------------------
>
>          Key: HHH-1724
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724
>      Project: Hibernate3
>         Type: Bug

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

>
>
> Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is.....
> created as blocker to make sure we either document or fix it.

-- 
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] Assigned: (HHH-1724) Critieria needs to be aligned with new aggreation type rules

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

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

Max Rydahl Andersen reassigned HHH-1724:
----------------------------------------

    Assign To: Max Rydahl Andersen

> Critieria needs to be aligned with new aggreation type rules
> ------------------------------------------------------------
>
>          Key: HHH-1724
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724
>      Project: Hibernate3
>         Type: Bug

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

>
>
> Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is.....
> created as blocker to make sure we either document or fix it.

-- 
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-9) Support interface inheritance mapping

[craig m. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-9?page=comments#action_23042 ] 

craig mcmillan commented on ANN-9:
----------------------------------

not ported yet... i will get round to it at some point, but i don't know when

> Support interface inheritance mapping
> -------------------------------------
>
>          Key: ANN-9
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-9
>      Project: Hibernate Annotations
>         Type: Improvement

>   Components: binder
>     Versions: 3.1beta3
>     Reporter: Gili
>  Attachments: hibernate3-annotations-3.1beta5-3896-3948.diff, hibernate3-annotations-3.1beta5-3896-4138.diff
>
>
> It should be possible to create a mapping with interfaces, as described by the documentation here: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#inheritance-tableperclass
> Specifically right now it is impossible to annotate interfaces and according to HBX-231 even if you could @Entity is only meant to get used on classes so the question becomes "what do you annotate it with?"
> As I pointed out here http://forum.hibernate.org/viewtopic.php?p=2238824#2238824 the additional problem seems to be that XDoclet doesn't support interface annotation either (http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1345) so I'm left without a workaround.
> I can't convert the interfaces to abstract classes because I implement multiple interfaces in my application and Java does not do multiple inheritance.
> If you know of a nice workaround, please let me know :)

-- 
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-1720) Incorrect Results from multi-valued query containing one-to-one

[Konstantin I. (JIRA) <no...@at...>]

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

Konstantin Ignatyev commented on HHH-1720:
------------------------------------------

Yes, that looks like bug, slightly changed query like this :
SELECT t.recordId, t.registryRecord, t.registryRecord.version FROM Record t WHERE t.recordId = ?
returns proper value for the version property of the registryRecord, but the registryRecord is still null

> Incorrect Results from multi-valued query containing one-to-one
> ---------------------------------------------------------------
>
>          Key: HHH-1720
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1720
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3, Oracle 10
>     Reporter: Mike Ringrose
>  Attachments: Record.hbm.xml, RecordRegistry.hbm.xml
>
>
> The Query below used to work correctly when using the classic query translator; however, no long returns the correct results with the ast query translator. WIth the ast query translator, the third result from the select, which is a one-to-one, always returns null even when the value exists.
> SELECT t.nameFirst, t.nameLast, t.registryRecord FROM Record t WHERE t.recordId = ?").setLong(0, 1);
> Running the query below with the ast query translator, works fine and always returns the correct results, that's why I beleive the problem to be only with multi-valued queries.
> SELECT t.registryRecord FROM Record t WHERE t.recordId = ?").setLong(0, 1);
> The code between session open and close is below:
> return (Object[])session.createQuery("SELECT t.recordId, t.registryRecord FROM com.imsweb.seerdms.shared.entity.Record t WHERE t.recordId = ?").setLong(0, 1).uniqueResult();

-- 
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-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

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

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

    Resolution: Rejected

We've thought about that already, but:
 - the spec does not allows that explicitly, it only pass the given entity
 - it would be quite inefficient to to support it since it would require multiple pre-flush phases

> 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-1720) Incorrect Results from multi-valued query containing one-to-one

[Konstantin I. (JIRA) <no...@at...>]

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

Konstantin Ignatyev commented on HHH-1720:
------------------------------------------

I am going to test validity of the report.

> Incorrect Results from multi-valued query containing one-to-one
> ---------------------------------------------------------------
>
>          Key: HHH-1720
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1720
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3, Oracle 10
>     Reporter: Mike Ringrose
>  Attachments: Record.hbm.xml, RecordRegistry.hbm.xml
>
>
> The Query below used to work correctly when using the classic query translator; however, no long returns the correct results with the ast query translator. WIth the ast query translator, the third result from the select, which is a one-to-one, always returns null even when the value exists.
> SELECT t.nameFirst, t.nameLast, t.registryRecord FROM Record t WHERE t.recordId = ?").setLong(0, 1);
> Running the query below with the ast query translator, works fine and always returns the correct results, that's why I beleive the problem to be only with multi-valued queries.
> SELECT t.registryRecord FROM Record t WHERE t.recordId = ?").setLong(0, 1);
> The code between session open and close is below:
> return (Object[])session.createQuery("SELECT t.recordId, t.registryRecord FROM com.imsweb.seerdms.shared.entity.Record t WHERE t.recordId = ?").setLong(0, 1).uniqueResult();

-- 
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-1726) Cloning an object with lazy initialization

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

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1726?page=all ]
     
Christian Bauer closed HHH-1726:
--------------------------------

    Resolution: Rejected

http://forum.hibernate.org

> Cloning an object with lazy initialization
> ------------------------------------------
>
>          Key: HHH-1726
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1726
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.1
>     Reporter: Guy Bashan

>
>
> I know this problem probably in not concerned directly wil Hibernate, but it is still a weird problem:
> I wrote a method for making a deep copy on some object that holds a lot of objects under it. I make the deep copy by simply looping all objects, cloning them and setting ids to null. It used to work great, untill I did the following thing:
> (It can be best demonstrated with an example)
> Suppose I have two objects A and B with One to Many relation (Meaning I have: "A.Bs" where "Bs" is a Set/List), I added also B entity as a member of A: For exmaple: "A.defaultB" where "defaultB" holds a single default value of B.
> Now, this causes an exception when using BeanUtils.clone, making it impossible to clone the object:
> 06/05/08 19:05:29 java.lang.NoSuchMethodException: Property 'callback' has no getter method
> 06/05/08 19:05:29 	at org.apache.commons.beanutils.PropertyUtils.getSimpleProperty(PropertyUtils.java)
> 06/05/08 19:05:29 	at org.apache.commons.beanutils.PropertyUtils.copyProperties(PropertyUtils.java:318)
> I assume the lazy initialization mechanism adds a member that cannot be copied to the newly created object.
> Is it possible that the lazy initialization mechanism makes it impossible to clone objects ???

-- 
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-1726) Cloning an object with lazy initialization

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

Cloning an object with lazy initialization
------------------------------------------

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

  Components: core  
    Versions: 3.1.1    
    Reporter: Guy Bashan


I know this problem probably in not concerned directly wil Hibernate, but it is still a weird problem:
I wrote a method for making a deep copy on some object that holds a lot of objects under it. I make the deep copy by simply looping all objects, cloning them and setting ids to null. It used to work great, untill I did the following thing:
(It can be best demonstrated with an example)
Suppose I have two objects A and B with One to Many relation (Meaning I have: "A.Bs" where "Bs" is a Set/List), I added also B entity as a member of A: For exmaple: "A.defaultB" where "defaultB" holds a single default value of B.
Now, this causes an exception when using BeanUtils.clone, making it impossible to clone the object:
06/05/08 19:05:29 java.lang.NoSuchMethodException: Property 'callback' has no getter method
06/05/08 19:05:29 	at org.apache.commons.beanutils.PropertyUtils.getSimpleProperty(PropertyUtils.java)
06/05/08 19:05:29 	at org.apache.commons.beanutils.PropertyUtils.copyProperties(PropertyUtils.java:318)

I assume the lazy initialization mechanism adds a member that cannot be copied to the newly created object.

Is it possible that the lazy initialization mechanism makes it impossible to clone objects ???

-- 
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-1725) lazy properties, events and collection xxx was not processed by flush exception and EJB3 incompatibility

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

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-870) support SQL updates in named queries

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

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

Emmanuel Bernard commented on HHH-870:
--------------------------------------

The spec is silent, it does not covers process or clustered cache.

> support SQL updates in named queries
> ------------------------------------
>
>          Key: HHH-870
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-870
>      Project: Hibernate3
>         Type: New Feature

>   Components: core
>  Environment: Hibernate 3.0.5, SQL Server 2000
>     Reporter: Nathan Moon
>     Assignee: Max Rydahl Andersen
>     Priority: Minor
>      Fix For: 3.2.0.cr2
>  Attachments: NativeSQLQueryPlan_withNamedParameters.java.txt, patch.txt
>
>
> currently attempting to execute a named <sql-query> that is an update statement throws java.lang.UnsupportedOperationException: Update queries only supported through HQL.
> In order to execute sql updates, the Session.connection() must be used directly.
> (see forum topic http://forum.hibernate.org/viewtopic.php?t=940281)
> It would be very nice to be able to be able to externalize SQL update statements and be able to run them with Session.getNamedQuery().

-- 
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