hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1552) Error when using ?1 and parameterList

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

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

Steve Ebersole updated HHH-1552:
--------------------------------

    Component: query-hql
                   (was: core)
     Priority: Blocker  (was: Major)

> Error when using ?1 and parameterList
> -------------------------------------
>
>          Key: HHH-1552
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1552
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.2.0.alpha1
>     Reporter: Emmanuel Bernard
>     Assignee: Steve Ebersole
>     Priority: Blocker
>      Fix For: 3.2.0

>
>
> select item from Item item where item.name in ( :n )
> query.setParameterList("n", list); works
> select item from Item item where item.name in ( ?1 )
> query.setParameterList("1", list); 
> raise an exception
> java.lang.NullPointerException
> 	at org.hibernate.hql.ast.ParameterTranslationsImpl.getNamedParameterSqlLocations(ParameterTranslationsImpl.java:59)
> 	at org.hibernate.loader.hql.QueryLoader.getNamedParameterLocs(QueryLoader.java:458)
> 	at org.hibernate.loader.hql.QueryLoader.bindNamedParameters(QueryLoader.java:481)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1577)
> 	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:333)
> 	at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
> 	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1105)
> 	at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> Note that select item from Item item where item.name =  ?1 
> works like a charm

-- 
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-1267) HQL: order-by clause column list

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

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

Steve Ebersole updated HHH-1267:
--------------------------------

    Component: query-hql
                   (was: core)

> HQL: order-by clause column list
> --------------------------------
>
>          Key: HHH-1267
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1267
>      Project: Hibernate3
>         Type: Improvement

>   Components: query-hql
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>     Priority: Minor
>      Fix For: 3.2.0

>
>
> HQL currently always results in using qualified column names in the order-by clause.  Some databases (ok DB2) actually do not support this in all cases.  And really according to the SQL spec, it is not the specified thing to do.  Essentially the SQL spec says that if select-clause column aliases are used, those column aliases (or the column indexes) should be used in the order-by clause.
> This should be the non-default behavior as it'll be more intensive of the query parser to achieve 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] Updated: (HHH-1050) HQL Unions

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

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

Steve Ebersole updated HHH-1050:
--------------------------------

    Component: query-hql
                   (was: core)

> HQL Unions
> ----------
>
>          Key: HHH-1050
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1050
>      Project: Hibernate3
>         Type: New Feature

>   Components: query-hql
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Add the ability to define unions in HQL.  Support will be initially limited to only:
> 1) scalar queries : select id from Animal union select id from Car
> 2) the same entity : from Animal where ... union from Animal where ...
> Support both UNION and UNION ALL

-- 
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-1709) Be able to raise ENFE rather than LIE in proxies

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

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

    Resolution: Fixed

AFAIK, what we have now is sufficient

> Be able to raise ENFE rather than LIE in proxies
> ------------------------------------------------
>
>          Key: HHH-1709
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1709
>      Project: Hibernate3
>         Type: New Feature

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

>
>
> For HEM and EJB3

-- 
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-1847) QBE 'like' clause with backslashes don't work with MySQL

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

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

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

applied.  thanks.

> QBE 'like' clause with backslashes don't work with MySQL
> --------------------------------------------------------
>
>          Key: HHH-1847
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1847
>      Project: Hibernate3
>         Type: Patch

>   Components: query-criteria
>     Versions: 3.2.0.cr2
>  Environment: 3.2.0.cr2, JBoss AS 4.0.4, MySQL 4.x or 5.x
>     Reporter: Scott Marlow
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0
>  Attachments: Example-patch.txt, LikeExpression-patch.txt, QueryCacheTest-patch.txt
>
>
> MySQL supports backslashes in the 'like' clause as a special escape character for expressing newline characters.  Many applications will want to disable this functionality in MySQL which can be done by specifying the escape character value as empty string or some other value.
> MySQL support recommends that customers either double up their backslashes or use the escape clause to specify a different escape character value than backslash.
> This patch adds a new method SetEscapeCharacter to org.hibernate.criterion.Example.  This is only used if the  'like' clause option is enabled.  Also added is org.hibernate.criterion.LikeExpression.  A new test case is added (for MySQL only) to org.hibernate.test.querycache.QueryCacheTest.
> Example.setEscapeCharacter allows a value to be specfied that will be used as the new escape character for the like clause.

-- 
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-1365) NPE AbstractEntityTuplizer.createProxy(AbstractEntityTuplizer.java:372) when trying to load a class defined in a signed/sealed JAR

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

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

Martin Schulz commented on HHH-1365:
------------------------------------

I'm running into the exact same issue...

We have signed the application jar, hibernate3.jar and cglib-2.1.3.jar.  No go.

Still happens in 3.2RC2.

Can CLIB produce correctly signed classes without having access to the proper keystore?
I don't think so.
Is there a way to bypass the security check?
Can this be done using appropriate priviledged blocks (doPriviledged())?

> NPE AbstractEntityTuplizer.createProxy(AbstractEntityTuplizer.java:372) when trying to load a class defined in a signed/sealed JAR
> ----------------------------------------------------------------------------------------------------------------------------------
>
>          Key: HHH-1365
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1365
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.1
>  Environment: Java1.5.06 Ant1.7alpha, hibernate 3.1
>     Reporter: Steve Loughran
>     Priority: Minor

>
>
> I'm testing what happens to hibernate when running against a signed JAR. The answer is: most tests pass. What fails is this test (Apache 2.0 license, BTW)
>     public void testDetachedObject() throws Exception {
>         Event event = createTestEvent();
>         session.save(event);
>         session.flush();
>         closeSession();
>         //here the event is detached.
>         //we change it outside an operation.
>         String text = "modified";
>         event.setText(text);
>         session = getSessionFactory().openSession();
>         Event merged=(Event) session.merge(event);
>         assertEquals(event, merged);
>         session.flush();
>         closeSession();
>         session = getSessionFactory().openSession();
>         Event loaded = (Event) session.load(Event.class, event.getKey());
>         assertEquals(text, loaded.getText());
>         assertEquals(event, loaded);
>     }
> the session.load operation is failing, with the short stack trace of:
> java.lang.NullPointerException
> at org.hibernate.tuple.AbstractEntityTuplizer.createProxy(AbstractEntityTuplizer.java:372)
> at org.hibernate.persister.entity.AbstractEntityPersister.createProxy(AbstractEntityPersister.java:3121)
> at org.hibernate.event.def.DefaultLoadEventListener.createProxyIfNecessary(DefaultLoadEventListener.java:232)
> at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:173)
> at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
> at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869)
> at org.hibernate.impl.SessionImpl.load(SessionImpl.java:788)
> at org.hibernate.impl.SessionImpl.load(SessionImpl.java:781)
> at d1.persist.test.SessionTest.testDetachedObject(SessionTest.java:155)
> The root cause is probably contained in the info that gets printed when the session starts up, complaining that things cant be added to sealed classes
>    [junit] 2261 ERROR org.hibernate.proxy.BasicLazyInitializer  - CGLIB Enhancement failed: d1.persist.Event
>     [junit] net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null
>     [junit] 	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
>     [junit] 	at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
>     [junit] 	at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
>     [junit] 	at org.hibernate.proxy.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:126)
>     [junit] 	at org.hibernate.proxy.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:41)
>     [junit] 	at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:161)
>     [junit] 	at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131)
>     [junit] 	at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:55)
>     [junit] 	at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64)
>     [junit] 	at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:257)
>     [junit] 	at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412)
>     [junit] 	at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108)
>     [junit] 	at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
>     [junit] 	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:215)
>     [junit] 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1154)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:375)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:533)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createFactory(Ejb3Configuration.java:109)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:155)
>     [junit] 	at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:82)
>     [junit] 	at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:37)
>     [junit] 	at d1.persist.PersistTools.createManagerFactory(PersistTools.java:82)
>     [junit] 	at d1.persist.PersistTools.createDefaultManagerFactory(PersistTools.java:76)
>     [junit] 	at d1.persist.test.Ejb3TestBase.setUp(Ejb3TestBase.java:27)
>     [junit] 	at junit.framework.TestCase.runBare(TestCase.java:125)
>     [junit] 	at junit.framework.TestResult$1.protect(TestResult.java:106)
>     [junit] 	at junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit] 	at junit.framework.TestResult.run(TestResult.java:109)
>     [junit] 	at junit.framework.TestCase.run(TestCase.java:118)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:203)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:328)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:736)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:605)
>     [junit] Caused by: java.lang.reflect.InvocationTargetException
>     [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [junit] 	at java.lang.reflect.Method.invoke(Method.java:585)
>     [junit] 	at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
>     [junit] 	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
>     [junit] 	... 33 more
>     [junit] Caused by: java.lang.SecurityException: class "d1.persist.Event$$EnhancerByCGLIB$$55c8eae8_2"'s signer information does not match signer information of other classes in the same package
>     [junit] 	at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
>     [junit] 	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
>     [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
>     [junit] 	... 39 more
>     [junit] 2262 WARN  org.hibernate.tuple.PojoEntityTuplizer  - could not create proxy factory for:d1.persist.Event
>     [junit] org.hibernate.HibernateException: CGLIB Enhancement failed: d1.persist.Event
>     [junit] 	at org.hibernate.proxy.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:132)
>     [junit] 	at org.hibernate.proxy.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:41)
>     [junit] 	at org.hibernate.tuple.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:161)
>     [junit] 	at org.hibernate.tuple.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:131)
>     [junit] 	at org.hibernate.tuple.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:55)
>     [junit] 	at org.hibernate.tuple.TuplizerLookup.create(TuplizerLookup.java:64)
>     [junit] 	at org.hibernate.tuple.EntityMetamodel.<init>(EntityMetamodel.java:257)
>     [junit] 	at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:412)
>     [junit] 	at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:108)
>     [junit] 	at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
>     [junit] 	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:215)
>     [junit] 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1154)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:375)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:533)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createFactory(Ejb3Configuration.java:109)
>     [junit] 	at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:155)
>     [junit] 	at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:82)
>     [junit] 	at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:37)
>     [junit] 	at d1.persist.PersistTools.createManagerFactory(PersistTools.java:82)
>     [junit] 	at d1.persist.PersistTools.createDefaultManagerFactory(PersistTools.java:76)
>     [junit] 	at d1.persist.test.Ejb3TestBase.setUp(Ejb3TestBase.java:27)
>     [junit] 	at junit.framework.TestCase.runBare(TestCase.java:125)
>     [junit] 	at junit.framework.TestResult$1.protect(TestResult.java:106)
>     [junit] 	at junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit] 	at junit.framework.TestResult.run(TestResult.java:109)
>     [junit] 	at junit.framework.TestCase.run(TestCase.java:118)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:203)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:328)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:736)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:605)
>     [junit] Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null
>     [junit] 	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
>     [junit] 	at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
>     [junit] 	at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
>     [junit] 	at org.hibernate.proxy.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:126)
>     [junit] 	... 30 more
>     [junit] Caused by: java.lang.reflect.InvocationTargetException
>     [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [junit] 	at java.lang.reflect.Method.invoke(Method.java:585)
>     [junit] 	at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
>     [junit] 	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
>     [junit] 	... 33 more
>     [junit] Caused by: java.lang.SecurityException: class "d1.persist.Event$$EnhancerByCGLIB$$55c8eae8_2"'s signer information does not match signer information of other classes in the same package
>     [junit] 	at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
>     [junit] 	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
>     [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
>     [junit] 	... 39 more
> No doubt there is some way to configure hibernate to create proxies in a different package, and I shall seek that option out. All I want to note here is that NPEs are not the best way to report failure. 

-- 
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-1858) wrong sql generated against many-to-any association table

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

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

    Fix Version: 3.2.0
     Resolution: Fixed

Completed.  See : org.hibernate.test.hql.ASTParserLoadingTest#testAnyMappingReference

> wrong sql generated against many-to-any association table
> ---------------------------------------------------------
>
>          Key: HHH-1858
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1858
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1 rc 1
>  Environment: tested against postgresql 8.1, OracleXE/10Gr, using hidernate3.&.rc1 and hibernate console3.1.0.beta5 (hibernate3.2.0.cr1)
>     Reporter: Erwan Le Goulven
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Specifying a column name different than 'id'  in <many-to-any> relation leads to uncorrect hql generated.
> <class name="com.lectra.mapgentest.domain.test.manytomany.ItemImpl" table="ITEM" lazy="true" dynamic-update="true">
> ...
> ..
>         <set name="classifs" table="CLASSIFIABLE_CLASSIFS_ITEM" lazy="true" inverse="false">
>             <key foreign-key="none">
>                 <column name="items_id" index="ITEM_MYTESTIN_IDX" />
>             </key>
>             <many-to-any id-type="java.lang.Long" meta-type="string">
>                 <meta-value value="ClassifFolder" class="com.lectra.mapgentest.domain.test.manytomany.ClassifFolderImpl" />
>                 <meta-value value="ClassifAxe" class="com.lectra.mapgentest.domain.test.manytomany.ClassifAxeImpl" />
>                 <column name="classifs_type" />
>                 <column name="classifs_id" />
>             </many-to-any>
>         </set>
> ..
> ...
> </class>
> Sample hql triggering error :
> from ItemImpl i
> inner join i.classifs c
> where c.id is not null
> Generated sq :
> select
>   itemimpl0_.id as id71_,
>   itemimpl0_.parent_id as parent2_71_ 
>  from
>   ITEM itemimpl0_ 
>  inner join
>   CLASSIFIABLE_CLASSIFS_ITEM classifs1_ 
>    on itemimpl0_.id=classifs1_.items_id 
>  where
>   classifs1_.id is not null
> The same trouble might occur on <any> relation, and the column name resolution is not done when dealing with hql constraints against the "any" side

-- 
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-1855) booleans not properly handled in assignment clause of UPDATE statements

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

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

    Resolution: Fixed

Done.

For boolean literals, the old code always routed "resolution" of the literals through Dialect.toBooleanValueString().  The new code utilizes the ExpectedTypeAwareNode infrastructure to inject an expected type into the BooleanLiteralNode, usually based on the type of the property against which the bool-literal is being compared.

For parameters, a drastic change was to make setBoolean() prefer the expected type.  This is different than all the other "typed param setters", in that all others prefer the explicit type over the expected type.

> booleans not properly handled in assignment clause of UPDATE statements
> -----------------------------------------------------------------------
>
>          Key: HHH-1855
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1855
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> booleans, either as literals or as parameters, are not properly handled when encountered in the assignment (SET) clause of UPDATE statements.  Specifically, they are not treated as the "correct" type.

-- 
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-1861) More complete component handling in HQL

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

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

    Resolution: Fixed

Done.  For databases not supporting row value constructor syntax, the AST is actually mutated such that:

(FIRST_NAME, LAST_NAME) = ('Steve', 'Ebersole')

actually becomes:

FIRST_NAME = 'Steve' AND LAST_NAME = 'Ebersole'

> More complete component handling in HQL
> ---------------------------------------
>
>          Key: HHH-1861
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1861
>      Project: Hibernate3
>         Type: Improvement

>   Components: query-hql
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
> Need more complete component handling capabilities in HQL.  Specifically, the following are great things to be able to do (Person.name is component):
> from Person p where p.name = :name
> from Person p where p.name = ('steve', 'ebersole')
> The last form loosely follows the ANSI-SQL construct of "row value constructor", and actually was previously supported on databases which supported this syntax.

-- 
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-1861) More complete component handling in HQL

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

More complete component handling in HQL
---------------------------------------

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

  Components: query-hql  
    Reporter: Steve Ebersole
 Assigned to: Steve Ebersole 
     Fix For: 3.2.0


Need more complete component handling capabilities in HQL.  Specifically, the following are great things to be able to do (Person.name is component):

from Person p where p.name = :name
from Person p where p.name = ('steve', 'ebersole')

The last form loosely follows the ANSI-SQL construct of "row value constructor", and actually was previously supported on databases which supported this syntax.

-- 
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-1746) NullPointerException at IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195

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

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

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

> NullPointerException at IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195
> ------------------------------------------------------------------------------------------
>
>          Key: HHH-1746
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1746
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.2.0 cr1
>     Reporter: Igor A Tarasov
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0

>
>
>  java.lang.NullPointerException
> 	at org.hibernate.hql.ast.tree.IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195)
> 	at org.hibernate.hql.ast.tree.IdentNode.resolve(IdentNode.java:85)
> 	at org.hibernate.hql.ast.tree.DotNode.resolveFirstChild(DotNode.java:139)
> 	at org.hibernate.hql.ast.HqlSqlWalker.lookupProperty(HqlSqlWalker.java:469)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.addrExpr(HqlSqlBaseWalker.java:4316)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1211)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3518)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.updateStatement(HqlSqlBaseWalker.java:358)
> 	at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:237)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:227)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:159)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110)
> 	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77)
> 	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56)
> 	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> 	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
> 	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
> 	at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1586)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:77)
> 	at org.dicr.isp.mbean.DataManager.deleteGroup(DataManager.java:121)
> 	at org.apache.jsp.admin.data.group_del_jsp._jspService(group_del_jsp.java:67)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
> 	... 17 more
> 194:  Type componentType = getNakedPropertyType(fromElement);
> 195:  if (!componentType.isComponentType()) {
> 196:        throw new QueryException("Property '" + getOriginalText() + "' is not a component.  Use an alias to reference associations or collections.");
> 197: }
> This occur if  EJB3-QL query contains this errors:
> update GroupDO set GroupDO._deleted = now() where GroupDO._id = ?1 and GroupDO._deleted is NULL
> Correct query work fine:
> update GroupDO set _deleted = now() where _id = ?1 and _deleted is NULL

-- 
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-1556) <list>, <bag> in component gives "null" list fields when querying (HQL)

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

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

    Resolution: Duplicate

> <list>, <bag> in component gives "null" list fields when querying (HQL)
> -----------------------------------------------------------------------
>
>          Key: HHH-1556
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1556
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>     Reporter: Fabio Tudone
>     Priority: Critical

>
>


-- 
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-1822) flushing entity linked to transient instance (non cascaded) should always fail

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

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

    Resolution: Fixed

> flushing entity linked to transient instance (non cascaded) should always fail
> ------------------------------------------------------------------------------
>
>          Key: HHH-1822
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1822
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Steve Ebersole
>     Priority: Critical
>      Fix For: 3.2.0

>
>
> A a = new A();
> B b = new B();
> a.setB(b);
> session.persist(a);
> session.flush(); //should fail in all cases same for collections
> esp when generator is assigned

-- 
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-1860) Autogeneration of primary keys for Sybase IDENTITY columns fails with latest jConn3 driver

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

Autogeneration of primary keys for Sybase IDENTITY columns fails with latest jConn3 driver
------------------------------------------------------------------------------------------

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

    Versions: 3.2.0 cr1    
 Environment: JBoss 4.0.4GA, Adaptive Server Anywhere 9, jConnect using com.sybase.jdbc3.jdbc.SybDriver / jConn3.jar
    Reporter: Erica Kane
    Priority: Minor


Sybase provides an IDENTITY column which is very useful for autogenerating primary keys for entity beans.  However, if version 6.05 of jConnect (the standard Sybase driver) is used, with com.sybase.jdbc3.jdbc.SybDriver, all inserts fail with a message that it was not possible to obtain the generated identity.

Changing the datasource configuration to use com.sybase.jdbc2.jdbc.SybDriver fixes the problem.

Hopefully this can be fixed -- I realize it may be Sybase's fault -- but if not, I hope this spares someone else the agony of figuring it out.

-- 
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-1822) flushing entity linked to transient instance (non cascaded) should always fail

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

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

Steve Ebersole commented on HHH-1822:
-------------------------------------

Doing some more tests right now, but I have code in place to account for this situation.  It required extending CascadingAction to add 2 new methods: requiresNoCascadeChecking() and noCascade().  Currently, I just have the JPA-specific PERSIST_ONPFLUSH CascadingAction doing anything special here.

Cascade.cascade() then uses the noCascade() call in the case where no cascade operation is defined to occur.

> flushing entity linked to transient instance (non cascaded) should always fail
> ------------------------------------------------------------------------------
>
>          Key: HHH-1822
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1822
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Steve Ebersole
>     Priority: Critical
>      Fix For: 3.2.0

>
>
> A a = new A();
> B b = new B();
> a.setB(b);
> session.persist(a);
> session.flush(); //should fail in all cases same for collections
> esp when generator is assigned

-- 
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-1828) registering a transaction marked for Rollback is illegal

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

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

Steve Ebersole reassigned HHH-1828:
-----------------------------------

    Assign To: Steve Ebersole

> registering a transaction marked for Rollback is illegal
> --------------------------------------------------------
>
>          Key: HHH-1828
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1828
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Steve Ebersole
>     Priority: Blocker
>      Fix For: 3.2.0

>
>
> org.hibernate.TransactionException: Could not register synchronization
> at org.hibernate.transaction.CMTTransaction.registerSynchronization(CMTTransaction.java:159)
> at org.hibernate.ejb.EntityManagerImpl.close(EntityManagerImpl.java:59)
> at org.jboss.ejb3.stateful.StatefulBeanContext.closeExtendedPCs(StatefulBeanContext.java:285)
> at org.jboss.ejb3.stateful.StatefulBeanContext.remove(StatefulBeanContext.java:269)
> ... 48 more
> Caused by: javax.transaction.RollbackException: Already marked for rollback, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1149964756546/52, BranchQual=null:1149964756546, localId=0:52]
> at org.jboss.tm.TransactionImpl.checkStatus(TransactionImpl.java:2753)
> at org.jboss.tm.TransactionImpl.registerSynchronization(TransactionImpl.java:1531)
> at org.hibernate.transaction.CMTTransaction.registerSynchronization(CMTTransaction.java:156) 
> True for CMT and JTA. JoinableCMTTransaction is safe.

-- 
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-1822) flushing entity linked to transient instance (non cascaded) should always fail

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

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

Steve Ebersole reassigned HHH-1822:
-----------------------------------

    Assign To: Steve Ebersole

> flushing entity linked to transient instance (non cascaded) should always fail
> ------------------------------------------------------------------------------
>
>          Key: HHH-1822
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1822
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>     Reporter: Emmanuel Bernard
>     Assignee: Steve Ebersole
>     Priority: Critical
>      Fix For: 3.2.0

>
>
> A a = new A();
> B b = new B();
> a.setB(b);
> session.persist(a);
> session.flush(); //should fail in all cases same for collections
> esp when generator is assigned

-- 
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-1859) Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes

[Jeffrey M. M. (JIRA) <no...@at...>]

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

Jeffrey M. Metcalf commented on HHH-1859:
-----------------------------------------

Thanks for the comments and feedback.  My apologies for opening the issue rather than going to the forum.  Based on my reading of the Hibernate source code, I felt confident that I knew what I wanted.  My workaround was to re-code the standard type classes with the formats I needed and put them earlier than hibernate3.jar in the class path.  This is a bad solution for obvious reasons even though it works exactly as I want.  I will implement extentions as you suggest.

> Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1859
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1859
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 configured against Oracle 9.2.0.6.
>     Reporter: Jeffrey M. Metcalf
>     Priority: Minor

>
>
> The org.hibernate.type.DateType, org.hibernate.type.TimeType, and org.hibernate.type.TimestampType use hard coded format strings and juva.util.SImpleDateFormat class to parse dates from and format dates to Strings.  It would be very useful to parameterize these formats and allow the user to configure them via hibernate.cfg.xml.  This becomes even more useful as the DOM4J XML serialization and deserialization proliferates in use and graduates from a development to a core Hibernate feature.
> The main case for parameterizing them is that the standard date and dateTime formats defined by the W3C XSD specification are respectively "yyyy-MM-dd" and "yyyy-MM-dd'T'HH:mm:ss".  Hibernate is not using these standard formats, therefore allowing the user to specify the formats at runtime provides the flexibility to allow standard XML formats (as well as others) to be used.

-- 
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: (ANN-369) @CollectionOfElements on a Map uses reserved word "key" as column name

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

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

Emmanuel Bernard reassigned ANN-369:
------------------------------------

    Assign To: Emmanuel Bernard

> @CollectionOfElements on a Map uses reserved word "key" as column name
> ----------------------------------------------------------------------
>
>          Key: ANN-369
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-369
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>  Environment: Hibernate 3.2.0cr1, MySQL 5
>     Reporter: Martin
>     Assignee: Emmanuel Bernard
>  Attachments: dont_use_key_for_maps.diff
>
>
> This annotation
> [User.java]
> @CollectionOfElements
> public Map<String, String> getMisc()
> results in this create table statement:
> create table User_misc (User_id bigint not null, element varchar(255), key varchar(255), primary key (User_id, key)) type=InnoDB
> But "KEY" is a reserved word, so MySQL won't create that table. The default column name should either change or be enclosed by backticks.

-- 
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-1859) Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes

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

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

    Resolution: Rejected

wrong resolution

> Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1859
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1859
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 configured against Oracle 9.2.0.6.
>     Reporter: Jeffrey M. Metcalf
>     Priority: Minor

>
>
> The org.hibernate.type.DateType, org.hibernate.type.TimeType, and org.hibernate.type.TimestampType use hard coded format strings and juva.util.SImpleDateFormat class to parse dates from and format dates to Strings.  It would be very useful to parameterize these formats and allow the user to configure them via hibernate.cfg.xml.  This becomes even more useful as the DOM4J XML serialization and deserialization proliferates in use and graduates from a development to a core Hibernate feature.
> The main case for parameterizing them is that the standard date and dateTime formats defined by the W3C XSD specification are respectively "yyyy-MM-dd" and "yyyy-MM-dd'T'HH:mm:ss".  Hibernate is not using these standard formats, therefore allowing the user to specify the formats at runtime provides the flexibility to allow standard XML formats (as well as others) to be used.

-- 
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-1859) Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes

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

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


> Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1859
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1859
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 configured against Oracle 9.2.0.6.
>     Reporter: Jeffrey M. Metcalf
>     Priority: Minor

>
>
> The org.hibernate.type.DateType, org.hibernate.type.TimeType, and org.hibernate.type.TimestampType use hard coded format strings and juva.util.SImpleDateFormat class to parse dates from and format dates to Strings.  It would be very useful to parameterize these formats and allow the user to configure them via hibernate.cfg.xml.  This becomes even more useful as the DOM4J XML serialization and deserialization proliferates in use and graduates from a development to a core Hibernate feature.
> The main case for parameterizing them is that the standard date and dateTime formats defined by the W3C XSD specification are respectively "yyyy-MM-dd" and "yyyy-MM-dd'T'HH:mm:ss".  Hibernate is not using these standard formats, therefore allowing the user to specify the formats at runtime provides the flexibility to allow standard XML formats (as well as others) to be used.

-- 
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-1859) Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes

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

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

    Resolution: Fixed

I don't what you suggest will work as you think it will.  That is because DateType, TimeType, and TimestampType are essentially statically built as part of TypeFactory startup.  Meaning, given:

<property name="xyz" type="date"/>

there is *no way* to parameterize that specified type.

Now what we could allow would be to "reuse" said types under different names with that given parameterization info.  However, org.hibernate.type.Type is *not* intended as an enxtension point; that is the role of the interfaces in the org.hibernate.usertype package.  And it is quite easy to do what you suggest using those interfaces...

> Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes
> ----------------------------------------------------------------------------------------------
>
>          Key: HHH-1859
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1859
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 configured against Oracle 9.2.0.6.
>     Reporter: Jeffrey M. Metcalf
>     Priority: Minor

>
>
> The org.hibernate.type.DateType, org.hibernate.type.TimeType, and org.hibernate.type.TimestampType use hard coded format strings and juva.util.SImpleDateFormat class to parse dates from and format dates to Strings.  It would be very useful to parameterize these formats and allow the user to configure them via hibernate.cfg.xml.  This becomes even more useful as the DOM4J XML serialization and deserialization proliferates in use and graduates from a development to a core Hibernate feature.
> The main case for parameterizing them is that the standard date and dateTime formats defined by the W3C XSD specification are respectively "yyyy-MM-dd" and "yyyy-MM-dd'T'HH:mm:ss".  Hibernate is not using these standard formats, therefore allowing the user to specify the formats at runtime provides the flexibility to allow standard XML formats (as well as others) to be used.

-- 
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: (ANN-369) @CollectionOfElements on a Map uses reserved word "key" as column name

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

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

Tristan Tarrant updated ANN-369:
--------------------------------

    Attachment: dont_use_key_for_maps.diff

Patch for Annotations which changes "key" to "mapkey". This bug causes problems with MySQL and SQLServer

> @CollectionOfElements on a Map uses reserved word "key" as column name
> ----------------------------------------------------------------------
>
>          Key: ANN-369
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-369
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>  Environment: Hibernate 3.2.0cr1, MySQL 5
>     Reporter: Martin
>  Attachments: dont_use_key_for_maps.diff
>
>
> This annotation
> [User.java]
> @CollectionOfElements
> public Map<String, String> getMisc()
> results in this create table statement:
> create table User_misc (User_id bigint not null, element varchar(255), key varchar(255), primary key (User_id, key)) type=InnoDB
> But "KEY" is a reserved word, so MySQL won't create that table. The default column name should either change or be enclosed by backticks.

-- 
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-1859) Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes

[Jeffrey M. M. (JIRA) <no...@at...>]

Parameterize string format in DateType, TimeType, and TimestampType org.hibernate.type classes
----------------------------------------------------------------------------------------------

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

  Components: core  
    Versions: 3.1.3    
 Environment: Hibernate 3.1.3 configured against Oracle 9.2.0.6.
    Reporter: Jeffrey M. Metcalf
    Priority: Minor


The org.hibernate.type.DateType, org.hibernate.type.TimeType, and org.hibernate.type.TimestampType use hard coded format strings and juva.util.SImpleDateFormat class to parse dates from and format dates to Strings.  It would be very useful to parameterize these formats and allow the user to configure them via hibernate.cfg.xml.  This becomes even more useful as the DOM4J XML serialization and deserialization proliferates in use and graduates from a development to a core Hibernate feature.

The main case for parameterizing them is that the standard date and dateTime formats defined by the W3C XSD specification are respectively "yyyy-MM-dd" and "yyyy-MM-dd'T'HH:mm:ss".  Hibernate is not using these standard formats, therefore allowing the user to specify the formats at runtime provides the flexibility to allow standard XML formats (as well as others) to be used.

-- 
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-1858) wrong sql generated against many-to-any association table

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

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

Steve Ebersole reassigned HHH-1858:
-----------------------------------

    Assign To: Steve Ebersole

> wrong sql generated against many-to-any association table
> ---------------------------------------------------------
>
>          Key: HHH-1858
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1858
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.1 rc 1
>  Environment: tested against postgresql 8.1, OracleXE/10Gr, using hidernate3.&.rc1 and hibernate console3.1.0.beta5 (hibernate3.2.0.cr1)
>     Reporter: Erwan Le Goulven
>     Assignee: Steve Ebersole

>
>
> Specifying a column name different than 'id'  in <many-to-any> relation leads to uncorrect hql generated.
> <class name="com.lectra.mapgentest.domain.test.manytomany.ItemImpl" table="ITEM" lazy="true" dynamic-update="true">
> ...
> ..
>         <set name="classifs" table="CLASSIFIABLE_CLASSIFS_ITEM" lazy="true" inverse="false">
>             <key foreign-key="none">
>                 <column name="items_id" index="ITEM_MYTESTIN_IDX" />
>             </key>
>             <many-to-any id-type="java.lang.Long" meta-type="string">
>                 <meta-value value="ClassifFolder" class="com.lectra.mapgentest.domain.test.manytomany.ClassifFolderImpl" />
>                 <meta-value value="ClassifAxe" class="com.lectra.mapgentest.domain.test.manytomany.ClassifAxeImpl" />
>                 <column name="classifs_type" />
>                 <column name="classifs_id" />
>             </many-to-any>
>         </set>
> ..
> ...
> </class>
> Sample hql triggering error :
> from ItemImpl i
> inner join i.classifs c
> where c.id is not null
> Generated sq :
> select
>   itemimpl0_.id as id71_,
>   itemimpl0_.parent_id as parent2_71_ 
>  from
>   ITEM itemimpl0_ 
>  inner join
>   CLASSIFIABLE_CLASSIFS_ITEM classifs1_ 
>    on itemimpl0_.id=classifs1_.items_id 
>  where
>   classifs1_.id is not null
> The same trouble might occur on <any> relation, and the column name resolution is not done when dealing with hql constraints against the "any" side

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