September 2010 - hibernate-issues

[Hibernate-JIRA] Created: (BVTCK-8) Update dependencies in pom

by Hardy Ferentschik (JIRA)

Update dependencies in pom -------------------------- Key: BVTCK-8 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-8 Project: Bean Validation TCK Issue Type: Task Affects Versions: 1.0.3.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.0.4 * Some of the plugins needs a explicit version * The test-harness dependency should be updated -- 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

15 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVTCK-9) Update docbook documentation

by Hardy Ferentschik (JIRA)

Update docbook documentation ---------------------------- Key: BVTCK-9 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-9 Project: Bean Validation TCK Issue Type: Task Affects Versions: 1.0.3.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.0.4 * Update docbook to the latest version * Introduce a js303-tck.ent file to externalize entity definitions * Use the docbook maven plugin functionality to filter in the current version of the pom * Fix some typos (eg table description of test harness execution) -- 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

15 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVTCK-7) Update all tests within a package to use the same resource includes via @Classes

by Hardy Ferentschik (JIRA)

Update all tests within a package to use the same resource includes via @Classes -------------------------------------------------------------------------------- Key: BVTCK-7 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-7 Project: Bean Validation TCK Issue Type: Bug Reporter: Hardy Ferentschik Assignee: Emmanuel Bernard Fix For: 1.0.4 The current test framework builds for each test a war file containing all classes within the package of the test class and all additional classes listed in the @Classes annotation. This can lead to problems when there are several tests in the same package using different resources - see [JBCTS-1039|https://jira.jboss.org/browse/JBCTS-1039]. For all tests within a package the @Classes annotation has to list the union of all required additional resources in the package. -- 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

15 years, 7 months

1
3
0 / 0

[Hibernate-JIRA] Created: (BVTCK-5) Provide separate signature files for Java 5 and Java 6

by Hardy Ferentschik (JIRA)

Provide separate signature files for Java 5 and Java 6 ------------------------------------------------------- Key: BVTCK-5 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-5 Project: Bean Validation TCK Issue Type: Task Affects Versions: 1.0.2.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.0.3 -- 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

15 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5583) Allow a more flexible mechanism for adding new functionality to HQL

by Fabio adriano Lisboa Gomes (JIRA)

Allow a more flexible mechanism for adding new functionality to HQL ------------------------------------------------------------------- Key: HHH-5583 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5583 Project: Hibernate Core Issue Type: New Feature Components: query-criteria, query-hql Reporter: Fabio adriano Lisboa Gomes Why not allow a more flexible mechanism for adding features not provided by HQL? Perhaps an escape mechanism, which can be placed in any position in the HQL. The HQL parser could call a method, for example, {{String escapeTranslator(String input)}}. Each dialect could have an implementation of this method. The default implementation could return the escape characters unchanged. The absence of a more flexible mechanism forces the use of hacks like the one described in the blog [http://www.znetdevelopment.com/blogs/2009/10/07/using-use-index-with-hibe...]. *For example*: Suppose the escape characters are delimited by slash slash (//). So we could write {{String HQL = select u from User u //use index (my_index)//}} If no specific implementation of {{escapeTranslator (..)}} is provided, the HQL parser could return {{select u from User u use index (my_index)}} This implementation is very flexible and at the same time, portable, since different dialects could provide their own implementations of the {{scapeTranslator}} method. The escape delimiters characters could be defined by {{query.setEscapeDelimiter (String begin, String end)}} -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-592) @TableGenerator realisation does not respect initialValue

by Christoph Schönfeld (JIRA)

@TableGenerator realisation does not respect initialValue --------------------------------------------------------- Key: ANN-592 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-592 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Reporter: Christoph Schönfeld Priority: Minor I would like to have generated IDs for a certain entity type start at the value of 1000. Consider the following example. @TableGenerator(name = "employee", table = "SEQUENCES", pkColumnName = "name", valueColumnName = "value", pkColumnValue = "employee", allocationSize = 10, initialValue = 1000) Hibernate generates the SEQUENCES table correctly but it always returns 1 as the first generated key. In the source code of AnnotationBinder.java which seems to be responsible for binding the @TableGenerator annotation to a MultipleHiLoPerTableGenerator instance the initialValue property 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

15 years, 7 months

6
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4690) Consider adding a flag for legacy/new generators

by Emmanuel Bernard (JIRA)

Consider adding a flag for legacy/new generators ------------------------------------------------ Key: HHH-4690 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4690 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
8
0 / 0

[Hibernate-JIRA] Created: (JPA-6) @ManyToOne target using Single Table inheritance type

by Michal Jastak (JIRA)

@ManyToOne target using Single Table inheritance type ----------------------------------------------------- Key: JPA-6 URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-6 Project: Java Persistence API Issue Type: Bug Affects Versions: 1.0.0 Environment: hibernate annotations 3.4.0 GA, hibernate entity manager 3.4.0 GA, spring framework 3.0.4, database: Mysql (tested on Oracle as well) Reporter: Michal Jastak It looks like the wrong SQL is generated when you use the @ManyToOne which target entity is using Single Table inheritance type, see the example below: @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) @DiscriminatorColumn(name = "D_TYPE") @Table(name = "DICTIONARIES") public abstract class DictionaryItem implements Serializable { private String description; private Long id; @Basic public String getDescription() { return description; } @Id public Long getId() { return id; } ... } @Entity @DiscriminatorValue("MaterialType") public class MaterialType extends DictionaryItem { // Empty by design ... } @Entity @javax.persistence.Table(name = "TABLES") public class Table implements Serializable { private Long id; private MaterialType legsMaterial; @Id public Long getId() { return id; } @ManyToOne @JoinColumn(name = "LEG_MATERIAL") public MaterialType getLegsMaterial() { return legsMaterial; } ... } @Repository("persistence.TableDAO") public class DefaultTableDAO implements TableDAO { @PersistenceContext private EntityManager entityManager; public Table get(Long id) { return entityManager.find(Table.class, id); } ... } DB tables: CREATE TABLE DICTIONARIES ( ID NUMERIC NOT NULL, D_TYPE VARCHAR(32), DESCRIPTION VARCHAR(64), CONSTRAINT DICTIONARIES_PK PRIMARY KEY (ID, D_TYPE) ); INSERT INTO DICTIONARIES(ID, D_TYPE, DESCRIPTION) VALUES (1, 'MaterialType', 'Wood'); INSERT INTO DICTIONARIES(ID, D_TYPE, DESCRIPTION) VALUES (2, 'MaterialType', 'Glass'); INSERT INTO DICTIONARIES(ID, D_TYPE, DESCRIPTION) VALUES (1, 'SomeOtherType', 'SOT1'); INSERT INTO DICTIONARIES(ID, D_TYPE, DESCRIPTION) VALUES (2, 'SomeOtherType', 'SOT2'); CREATE TABLE TABLES ( ID NUMERIC NOT NULL, LEG_MATERIAL NUMERIC, CONSTRAINT TABLES_PK PRIMARY KEY (ID) ); INSERT INTO TABLES(ID, LEG_MATERIAL) VALUES (1, 1); Now let's try to fetch the table having id 1 with following code: Table table = tableDAO.get(1L); this will cause hibernate to execute the SQL query: select table0_.id as id0_1_, table0_.LEG_MATERIAL as LEG2_0_1_, materialty1_.id as id1_0_, materialty1_.description as descript3_1_0_ from TABLES table0_ left outer join DICTIONARIES materialty1_ on table0_.LEG_MATERIAL=materialty1_.id where table0_.id=? with parameter 1 (table id) which leads to the following result set: +--------+-----------+--------+----------------+ | id0_1_ | LEG2_0_1_ | id1_0_ | descript3_1_0_ | +--------+-----------+--------+----------------+ | 1 | 1 | 1 | Wood | | 1 | 1 | 1 | SOT1 | +--------+-----------+--------+----------------+ as you see - there is missing discriminator part of where clause for the material 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3018) Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update.

by Nicolas Cazottes (JIRA)

Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update. ------------------------------------------------------------------------------------------------------------------------ Key: HHH-3018 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3018 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Reporter: Nicolas Cazottes Attachments: testXMLTypeUpdates.zip While analyzing the SQL queries Hibernate generates to persist objects, I fall on a behaviour, that I first found strange, which is that in one flush of one transaction, there may be both an insert and an update for a given entity. My first expectation was to have only one insert and no update. After a few search, I discover that conversation (http://forum.hibernate.org/viewtopic.php?p=2191664&sid=c571096bda4a6b636e...) that explains it is normal in the case of a save with modifications after save. I discover (cf the classes of my zip showing it) that this behaviour is also present in the case of a relation that is managed by cascade. What I noticed is that the insert of the related entity is planned when the first hql query is executed after the relation has been established. So if the related entity is modified after the query execution (for exemple depending on the result of the query), an update will be executed. This behaviour is understandable but in my case, the update is really expensive (because it acts on an XMLType column) and unless I set a FlushMode to COMMIT (which I found really not a good solution), I can not control that Hibernate will generate both an insert and an update or only an insert. I know I could also set the relation just before the commit in order to avoid insert+update but this solution is not possible in my case and I find it not elegant (it would break the semantic of the cascade of the relation). I suggest to introduce a new configuration element (similar to the flushmode) in Hibernate in order to be able to have control whether Hibernate generates an insert containing the data of the entity at the first save or an insert containing the data of the entity at the flushing time. Note : The attached files (which is the smallest extraction of what does my application) shows that behaviour both for the save call and the cascade declenched by a query. Note2 : I found an issue in jira number 2621 submited by someone else that is related to this subject in think. -- 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

15 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-817) Projection aliases should not be applied to where-clause (Milosz Tylenda)

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-817?page=co... ] Gail Badner commented on HHH-817: --------------------------------- Hi Mark, our focus is on 3.6.0, so this probably will not be backported to 3.5.x. If no serious bugs are reported on 3.6.0-CR1 in the next 2 weeks, it will be made final. > Projection aliases should not be applied to where-clause (Milosz Tylenda) > ------------------------------------------------------------------------- > > Key: HHH-817 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-817 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5, 3.5.5, 3.6.0.Beta3 > Environment: Oracle 9.2.0.6, Hibernate 3.0.5, Spring Framework 1.2.2 based application working on Jakarta Tomcat 5.0.28 > Reporter: Michal Jastak > Assignee: Gail Badner > Fix For: 3.6.0.Beta4 > > Attachments: HHH-817.patch, HHH-817_3.3.2GA_17882.patch > > > following java code: > protected Entity loadEntityLightweight(Serializable entityId) throws DataAccessException { > Criteria criteria = getSession().createCriteria(Entity.class); > ProjectionList projectionList = Projections.projectionList(); > projectionList.add(Property.forName(BaseEntity.PROP_ID), BaseEntity.PROP_ID); > projectionList.add(Property.forName(BaseEntity.PROP_TYPE), BaseEntity.PROP_TYPE); > criteria.setProjection(projectionList); > criteria.add(Restrictions.eq(BaseEntity.PROP_ID, entityId)); > criteria.setResultTransformer(new AliasToBeanResultTransformer(Entity.class)); > return (Entity) criteria.uniqueResult(); > } > generates following SQL query: > select this_.id as y0_, this_.type as y1_ from entities this_ left outer join facilities this_1_ on this_.id=this_1_.id left outer join users this_2_ on this_.id=this_2_.id left outer join addresses address2_ on this_.address_id=address2_.id left outer join entities entity3_ on this_2_.employer_id=entity3_.id left outer join facilities entity3_1_ on entity3_.id=entity3_1_.id left outer join users entity3_2_ on entity3_.id=entity3_2_.id where y0_=? > y0_ = ? expression in where clause is causing a 904 error on Oracle 9: > ORA-00904: "Y0_": invalid identifier > hibernate dialect: org.hibernate.dialect.Oracle9Dialect > mapping for Entity class: > <?xml version="1.0"?> > <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" > "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> > <hibernate-mapping default-lazy="false" default-cascade="save-update"> > > <class name="Entity" table="entities" mutable="true"> > <id name="id" type="java.lang.Long" unsaved-value="null"> > <generator class="sequence"> > <param name="sequence">entities_id_seq</param> > </generator> > </id> > <many-to-one name="address" class="Address" column="address_id" /> > ... >  > <joined-subclass name="Facility" table="facilities"> > <key column="id" /> > ... > <set name="users" inverse="true" lazy="true"> > <key column="facility_id" /> > <one-to-many class="User" /> > </set> > </joined-subclass> >  > <joined-subclass name="User" table="users" dynamic-insert="true" dynamic-update="true"> > <key column="id" /> > <many-to-one name="employer" class="Entity" column="employer_id" cascade="none" /> > ... > <set name="userAuthorities" inverse="true" cascade="all-delete-orphan"> > <key column="user_id" /> > <one-to-many class="Authority" /> > </set> > </joined-subclass> > </class> > </hibernate-mapping> -- 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

15 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2010