November 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4556) session is not flushed before criteria query with subselect

by Jean-Baptiste Nizet (JIRA)

session is not flushed before criteria query with subselect ----------------------------------------------------------- Key: HHH-4556 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4556 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Reporter: Jean-Baptiste Nizet With flush mode AUTO, if I persist some instances of an entity class "A" and then run a criteria query on this entity (for example, the criteria equivalent of select a from A a where a.prop = 'foo'), Hibernate flushes the session before executing the query. However, if the criteria doesn't query on this entity, but contains a subquery which does (for example, the criteria equivalent of select B.id from B b where b.id not in (select a.b.id from A a where a.prop = 'foo')), Hibernate should flush the session but doesn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1008) SchemaValidator mapping of double to SQL-Type DECIMAL with Precision and Scale

by Julien HENRY (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1008?page=c... ] Julien HENRY commented on HHH-1008: ----------------------------------- Same problem for me with Oracle 9i and Hibernate 3.5.0-Beta-2: Mapping is: @Column(name="DATE_STRUC", precision=6, scale=3) private Double dateStructure; SQL Type in DB is NUMBER(6,3) Hibernate validation fails with: org.hibernate.HibernateException: Wrong column type in S3.DECOM for column DATE_STRUC. Found: number, expected: double precision at org.hibernate.mapping.Table.validateColumns(Table.java:284) [hibernate-core-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1156) [hibernate-core-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:139) [hibernate-core-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:364) [hibernate-core-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1367) [hibernate-core-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:858) [hibernate-annotations-3.5.0-Beta-2.jar:3.5.0-Beta-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:733) [hibernate-entitymanager-3.5.0-Beta-2.jar:3.5.0-Beta-2] > SchemaValidator mapping of double to SQL-Type DECIMAL with Precision and Scale > ------------------------------------------------------------------------------ > > Key: HHH-1008 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1008 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 beta 2 > Environment: DB2, Win2k > Reporter: Phritz Grau > Assignee: Diego Plentz > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am using the new SchemaValidator, it really is very useful. 1000x thanks. > However we have one problem. > Our tables contain a lot columns of SQL-Type DECIMAL with precision and scale. > These are mapped to double or java.lang.Double and > we specify the mapping like e.g.: > <property > name="doubleVal" > type="double"> > <column name="dVal" precision="12" scale="6"/> > </property> > Using the SchemaValidator results in an error: > org.hibernate.HibernateException: Wrong column type: dVal, expected: double > at org.hibernate.mapping.Table.validateColumns(Table.java:205) > at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:938) > Since there is not appropriate java type for sql type decimal, > it would be very nice if the above error is omittet, > when the mapping contains the correct precision and scale > values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1595) SQL syntax error on delete statement with subselect

by Strong Liu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1595?page=c... ] Strong Liu commented on HHH-1595: --------------------------------- https://jira.jboss.org/jira/browse/JBPAPP-1328 > SQL syntax error on delete statement with subselect > --------------------------------------------------- > > Key: HHH-1595 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1595 > Project: Hibernate Core > Issue Type: Bug > Components: query-hql > Affects Versions: 3.1.3 > Environment: Hibernate 3.1.3, Oracle 10g > Reporter: Georgios Skempes > Assignee: Strong Liu > > After upgrading from Hibernate 3.1.2 to 3.1.3 I get an SQL syntax error for the HQL statement below. It's a bulk delete containing a subselect. The code is working for Hibernate 3.1.2 > Code between session.open() and session.close(): > ------------------------------------------------------------------------ > String queryString = "delete from Contact con where con.Id.ConpId IN (select conp.Id from con.ContactpersonSet conp where conp.ParId=4711) > Query queryObject = session.createQuery(queryString); > queryObject.executeUpdate(); > SQL code generated with Hibernate 3.1.2 (correct): > ---------------------------------------------------------------------- > delete from CONTACTS where CONP_ID in (select contactper1_.Id from CONTACTPERSONS contactper1_ where CONP_ID=contactper1_.Id and PAR_ID=4711) > SQL code generated with Hibernate 3.1.3 (error): > ----------------------------------------------------------------------- > delete from CONTACTS where CONP_ID in (select contactper1_.Id from CONTAKTPERSONS contactper1_ where contact0_.CONP_ID=contactper1_.Id and contactper1_.PAR_ID=?) > Error log: > ----------------------------------------------------------------------- > [08:43:01,591] (ERROR) org.hibernate.util.JDBCExceptionReporter.logExceptions(JDBCExceptionReporter.java:72) - ORA-00904: "CONTACT0_"."CONP_ID": invalid identifier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1853) CREATE SCHEMA inside database-object need to execute before tables are created

by Johnathan James (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853?page=c... ] Johnathan James commented on HHH-1853: -------------------------------------- This issue should be fixed. All that is necessary is an option to force creation of the schemas if none are present. Users should not have to update and recompile code to make this happen. Its been over three years at this point. > CREATE SCHEMA inside database-object need to execute before tables are created > ------------------------------------------------------------------------------ > > Key: HHH-1853 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853 > Project: Hibernate Core > Issue Type: Improvement > Affects Versions: 3.1.3 > Environment: hsqldb 1.8.0 > Reporter: Mattias Jiderhamn > Priority: Minor > Attachments: create-schema.patch, create-schema2.patch > > > In order to have Hibernate create database schemas for hsqldb, you have to insert a <database-object> in your mapping file (http://forums.hibernate.org/viewtopic.php?p=2305138). Problem is, all the database-object statements are executed after the tables are created, so tables in non-default schemas will not be created. To get around this, you have to first use Configuration.generateSchemaCreationScript() to get the schemas, and then Configuration.generateSchemaUpdateScript() to get the tables inside the schemas. > (This is a bit problematic when using Springs LocalSessionFactoryBean) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (METAGEN-8) Processor does not handle @ElementCollection on a Map

by Hardy Ferentschik (JIRA)

Processor does not handle @ElementCollection on a Map ----------------------------------------------------- Key: METAGEN-8 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-8 Project: Hibernate StaticMetamodel Generator Issue Type: Bug Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1829) Allow join on any property using property-ref

by Gergely K (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829?page=c... ] Gergely K commented on HHH-1829: -------------------------------- This missing feature is most disturbing. Based on the documentation we expected that we can create a mapping for a legacy database, collecting only the necessary columns into an entity from multiple tables. Now, this is impossible because of this limitation. > Allow join on any property using property-ref > --------------------------------------------- > > Key: HHH-1829 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1829 > Project: Hibernate Core > Issue Type: New Feature > Components: metamodel > Affects Versions: 3.2.0 cr1, 3.2.0.cr2 > Reporter: Maarten Winkels > Assignee: Anthony Patricio > Attachments: AbstractJoinTest.java, HHH-1829-3.2.8-SNAPSHOT.patch, HHH-1829-mwinkels.patch, hhh-1829.patch, JoinNoPropertyRefTest.java, JoinPropertyRefTest.java, Person.hbm.xml, Person.java, PersonNoPropertyRef.hbm.xml > > > Currently joining tables for one class (uing the <join...> tag) is only supported for the id property. The property-ref is allowed on the <key..> tag inside the <join..> tag, but this is ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2897) Adding support for use of sequence objects in DB2 V8 OS390

by Tobias Sternvik (JIRA)

Adding support for use of sequence objects in DB2 V8 OS390 ---------------------------------------------------------- Key: HHH-2897 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2897 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Environment: Hibernate Core 3.2.5ga, DB2 UDB V8 OS390 (Z/OS) Reporter: Tobias Sternvik Attachments: DB2390Dialect.java Since version 8 of DB2 sequence objects are supported on the OS390 platform. But, the syntax for use of sequences varies between OS390 platform and the "rest". For retreival of next value in DB2 OS390 the syntax is "select nextval for <theSequenceName> from sysibm.sysdummy1" while in the "rest" it is "values nextval for <theSequenceName>". There migt be the case that within AS/400 environment the syntax is imilar to OS390, but I have not verified this. Also other differences exists.. I've included a enhanced verion of DB2390Dialect.java that has been proven to work in DB2 mainframe environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4547) IdGenerator + CompositeId = HibernateException: identifier of an instance of _ was altered

by David M. Lee (JIRA)

IdGenerator + CompositeId = HibernateException: identifier of an instance of _ was altered ------------------------------------------------------------------------------------------ Key: HHH-4547 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4547 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: Hibernate 3.3.2, seen on HSQLDB and PostgreSQL Reporter: David M. Lee Priority: Minor Attachments: composite-key-bug.tar.gz I have some legacy code that I'm working with that uses composite-id for some entities, and has an IdGenerator for the id's. The generator generates the id's correctly, but they do not get set on the entities when they are saved. For the base class, this results in the following exception: org.hibernate.HibernateException: identifier of an instance of org.hibernate.example.compositeid.EntityWithCompositeId was altered from CompositeId{id1=1, id2=1} to CompositeId{id1=null, id2=null} at org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:81) at org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:49) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028) Strangely, on subclasses we do not get this exception. I've attached an example, which has a couple of unit tests that demonstrate the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-465) order by nulls first / last

by Paul Benedict (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-465?page=co... ] Paul Benedict commented on HHH-465: ----------------------------------- Couldn't this be another dialect method like isNullOrderingSupported()? > order by nulls first / last > --------------------------- > > Key: HHH-465 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-465 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.0.3 > Reporter: Anthony Patricio > Priority: Minor > Attachments: CustomNullsFirstInterceptor.java > > > support of nulls first / last in order clause > "NULLS LAST" is part of the SQL 99 standard. > The syntax is as follows: > ORDER BY [COLUMN NAME] [ASC | DESC] [NULLS FIRST | NULLS LAST] > In different DBs, the sorting of nulls relative to other values is handled differently. > PostgreSQL - Nulls are considered HIGHER than non-nulls. > DB2 - Higher > MSSQL - Lower > MySQL - Lower > Oracle - Higher > The following DBs have supported this functionality: > DB2 V7 > Oracle 9i > PostgreSQL, MySQL, SQLServer do not appear to support this from what I can gather. > see http://forum.hibernate.org/viewtopic.php?t=942176&start=0&postdays=0&post... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-201) IndexWriter settings meant for transactional operations won't be inherited by the settings meant for batch operations

by Sanne Grinovero (JIRA)

IndexWriter settings meant for transactional operations won't be inherited by the settings meant for batch operations --------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-201 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-201 Project: Hibernate Search Issue Type: Deprecation Components: engine Reporter: Sanne Grinovero Priority: Minor Fix For: 3.2.0 Currently if a property has been set for "transaction" but not for "batch", the batch operation will use the same setting as defined in the transaction property; It appears to be a bit confusing and difficult to understand which settings are being set. Current inheritance is to be considered "deprecated" and will be disabled, please begin declaring both values independently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2009