March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HHH-354) property named "full" breaks HQL queries

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-354?page=co... ] Steve Ebersole closed HHH-354. ------------------------------ Closing stale resolved issues > property named "full" breaks HQL queries > ---------------------------------------- > > Key: HHH-354 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-354 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0 final > Environment: Hibernate 3.0, Oracle 9, JDK 1.5 > Reporter: Tim McCune > Assignee: Joshua Davis > Priority: Minor > Fix For: 3.1 beta 1 > > > Hibernate doesn't seem to be able to parse an HQL query that references a property named "full". I assume this is because "full" is a keyword in HQL, but the parser should be smart enough to realize that if "full" is preceded by a ".", then it's a property name. For instance, the HQL query "select bar.foo from Bar bar where bar.full = true" causes a "QuerySyntaxError: unexpected AST node: ." at the index of the . in "bar.full" -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1103) finalize method filter for proxies

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1103?page=c... ] Steve Ebersole closed HHH-1103. ------------------------------- Closing stale resolved issues > finalize method filter for proxies > ----------------------------------- > > Key: HHH-1103 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1103 > Project: Hibernate Core > Issue Type: Patch > Affects Versions: 3.0 alpha, 3.0 beta 1, 3.0 beta 2, 3.0 beta 3, 3.0 beta 4, 3.0 rc 1, 3.0 final, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.1 beta 1, 3.1 beta 2, 3.1 rc 1, 3.1 rc2, 3.1 rc3, 3.1.1, 3.1.2, 3.2.0.alpha1 > Environment: Any > Reporter: Juozas Baliuka > Assignee: Gavin King > Fix For: 3.1 rc3 > > Attachments: patch.txt, test-patch.txt > > > This proxy factory doe's not owrride "finalize" method, it must improve proxy garbage collection. -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-930) update ... set foo=null

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-930?page=co... ] Steve Ebersole closed HHH-930. ------------------------------ Closing stale resolved issues > update ... set foo=null > ----------------------- > > Key: HHH-930 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-930 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: Gavin King > > We need to be able to support setting things to null in an update statement. -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1047) replicate() does not handle cascade correctly

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1047?page=c... ] Steve Ebersole closed HHH-1047. ------------------------------- Closing stale resolved issues > replicate() does not handle cascade correctly > --------------------------------------------- > > Key: HHH-1047 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1047 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 rc 1 > Environment: 3.1b3, postgres 8 > Reporter: snorbii > > Hello, > I'm working with sequence-based identifiers, connected to a long property. > My workflow: > - I have an already saved object A. > - A is disconnected for editing by the UI layer. > - After editing is ready I call replicate() (with replication mode "latest") to synchronize with the database. > My problem is that during editing a new, unsaved object B is added to a many-to-one association of A. This many-to-one association has CascadeType.ALL. > - When replicate() is executed, it correctly cascades the replication. > - But in DefaultReplicateEventListener.onReplicate() I found the following code: > // get the id from the object > /*if ( persister.isUnsaved(entity, source) ) { > throw new TransientObjectException("transient instance passed to replicate()"); > }*/ > Serializable id = persister.getIdentifier( entity, source.getEntityMode() ); > if (id==null) { > throw new TransientObjectException("instance with null id passed to replicate()"); > } > > persister.getIdentifier() returns 0 because object B is unsaved. > This means that Hibernate does not realize that it is an unsaved object. > So it generates an SQL INSERT for inserting it as a new object, but without generating an ID for it. > The result is that object B is inserted to the database with ID=0 instead of an ID got from the sequence. > If object A has two such associations then two rows are inserted with ID=0 which causes constraint violation. > I think that it would be more correct if replication would save the associated unsaved object B with a normally generated ID if it is unsaved. > (Am I right that CASCADED replication should save transient instances instead of throwing an exception?) > BR, > Norbi -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-873) referencing raw HQL FromElement alias outide the from clause of update and delete statements generates incorrect sql

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-873?page=co... ] Steve Ebersole closed HHH-873. ------------------------------ Closing stale resolved issues > referencing raw HQL FromElement alias outide the from clause of update and delete statements generates incorrect sql > -------------------------------------------------------------------------------------------------------------------- > > Key: HHH-873 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-873 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: 2.6.11-gentoo-r4 > sun-jdk-1.5.0.04 > jboss-4.0.3RC1 (I guess 3.1alpha1) > postgresql-8.0.3 > jdbc3-postgresql-7.4.5 > Reporter: Emmanuel Bernard > Assignee: Steve Ebersole > Fix For: 3.1 rc 1 > > > Move from http://jira.jboss.com/jira/browse/EJBTHREE-259 > Two very simple entities one owns the other with OneToOne Cascade=ALL > relation. > @Entity > E1 > @id AUTO > long id > @OneToOne(Cascade=ALL) > E2 e2 > @Entity > E2 > @id AUTO > long id > This HQL is intended to delete all orphan e2 entities. > HQL : > "delete from E2 e2 where e2 not in (select e1.e2 from E1 e1 where e1.e2 is not null)" > it generates on postgresql > "delete from E2 where e2x0_.id not in (select e2_id from E1 e1x1_ where e2x_id is not null)" > which misses the E2 table alias and fails with "relation e2x0_ does not exist". > If I use instead > HQL : > "delete from E2 e2 where e2.id not in (select e1.e2.id from E1 e1 where e1.e2 is not null)" > then it generates: > "delete from E2 where id not in (select e2_id from E1 e1x1_ where e2x_id is not null)" > which does not access id by table alias and succeeds. > I guess table aliases are not always correctly generated -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1339) empty property name in mapping file gives imcomprehensible error message

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1339?page=c... ] Steve Ebersole closed HHH-1339. ------------------------------- Closing stale resolved issues > empty property name in mapping file gives imcomprehensible error message > ------------------------------------------------------------------------ > > Key: HHH-1339 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1339 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 > Environment: hibernate 3.1 > Reporter: Loren Rosen > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.1.1 > > > If you have a line in a hibernate mapping file like this: > <property name="" /> > the result is this error message: > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(String.java:444) > at org.hibernate.mapping.Column.setName(Column.java:60) > at org.hibernate.cfg.HbmBinder.bindColumns(HbmBinder.java:1033) > at org.hibernate.cfg.HbmBinder.bindColumnsOrFormula(HbmBinder.java:1437) > at org.hibernate.cfg.HbmBinder.bindSimpleValue(HbmBinder.java:1069) > at org.hibernate.cfg.HbmBinder.createClassProperties(HbmBinder.java:1982) > at org.hibernate.cfg.HbmBinder.createClassProperties(HbmBinder.java:1940) > at org.hibernate.cfg.HbmBinder.bindRootPersistentClassCommonValues(HbmBinder.java:324) > at org.hibernate.cfg.HbmBinder.bindRootClass(HbmBinder.java:238) > at org.hibernate.cfg.HbmBinder.bindRoot(HbmBinder.java:109) > at org.hibernate.cfg.Configuration.add(Configuration.java:385) > at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:426) > at org.hibernate.cfg.Configuration.addResource(Configuration.java:481) > at org.hibernate.cfg.Configuration.parseMappingElement(Configuration.java:1443) > at org.hibernate.cfg.Configuration.parseSessionFactory(Configuration.java:1411) > at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1392) > at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1368) > at org.hibernate.cfg.Configuration.configure(Configuration.java:1288) > at org.hibernate.cfg.Configuration.configure(Configuration.java:1274) > at com.loren.SimpleExample.startHibernate(SimpleExample.java:37) > at com.loren.SimpleExample.main(SimpleExample.java:45) > The user should get a clearer error message, not a strack trace that looks like an internal hibernate > programming error. -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1635) optimistic locking doesn't work if you change version manually in hibernate object

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1635?page=c... ] Steve Ebersole closed HHH-1635. ------------------------------- Closing stale resolved issues > optimistic locking doesn't work if you change version manually in hibernate object > ---------------------------------------------------------------------------------- > > Key: HHH-1635 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1635 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.0.5 > Environment: Running on debian sarge (stable) linux with spring framework 1.2.7. > Reporter: Ryan > > Essentially i am changing the version value in hibernate manually to an old version in the process of copying modified values from a DTO/View object. I use the version value from when I originally requested the view dto data. From my point of view, I would expect that this would cause Optimistic locking exceptions when the data/version was already changed by another client update. This seems like a common pattern. It does not work in this manner, it seems to always use the version in cache from the load and only consider the version change i make as an updage value rather then an actual change to the version. > It seems to me if hibernate intends to just ignore my version changes completely then what is the point of us even having a version property in our beans, why doesn't hibernate just use like a proxy and completely automate versioning, it is like it is teasing us with a property that is there but we can't use? > I have asked this problem in the forum and I have seen it asked before in both the forum and the bug tracker. I have spent some time searching for a detailed explination of why this doesn't work how I would expect it to and can't. > The topic in the forum I have opened. > http://forums.hibernate.org/viewtopic.php?t=957539&highlight=&sid=5c748ea... > PLEASE before you reject this i would appreciate and explination i really searched the forums heavily but couldn't find anything explaining this. Clearly I must not understand transaction management and optimistic locking as well as I should, and I just don't understand why this doesn't work like I am intending it to. -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HBX-289) In Artifact Generator, char(32) type convert to java.lang.Character

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-289?page=co... ] Steve Ebersole closed HBX-289. ------------------------------ Closing stale resolved issues > In Artifact Generator, char(32) type convert to java.lang.Character > ------------------------------------------------------------------- > > Key: HBX-289 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-289 > Project: Hibernate Tools > Issue Type: Bug > Components: reverse-engineer > Affects Versions: 3.0alpha4 > Environment: Java Version: 1.4.2_06-b03 > OS Name: Windows XP > OS Arch: x86 > OS Version: 5.1 > Adaptive Server Enterprise/12.5.2/EBF 11948 ESD#1/P/NT (IX86)/OS jConnect (TM) for JDBC(TM)/5.5(Build 25100)/P/EBF9853/JDK12/Fri Oct > Eclipse 3.1M6 > Reporter: Etienne Laverdiere > Fix For: 3.1alpha5 > > > When doing the reverse enginnering of a Sybase database (didn't try other), it convert all CHAR Data Type to Character Java Type. > Per example : on this table > create table AstRegion ( > astRegion char(6) not null, > astCountry char(3) null, > astType char(1) not null, > astDescription char(32) not null, > astLastMaintUser char(10) not null, > astLastMaintType char(1) not null, > astLastMaintJob char(10) not null, > astLastMaintTime numeric(6) not null, > astLastMaintDate numeric(8) not null, > constraint PK_ATFR3600 primary key (astRegion), > constraint FK_ATFR3600_REFERENCE_ATFR1900 foreign key (astCountry) > references AstCountry (astCountry) > ) > go > I get this java code: > /** > * AstRegion generated by hbm2java > */ > public class AstRegion implements java.io.Serializable { > // Fields > private java.lang.Character AstRegion; > private AstCountry AstCountry; > private java.lang.Character AstType; > private java.lang.Character AstDescription; > private java.lang.Character AstLastMaintUser; > private java.lang.Character AstLastMaintType; > private java.lang.Character AstLastMaintJob; > private java.lang.Integer AstLastMaintTime; > private java.lang.Integer AstLastMaintDate; > // Constructors > /** default constructor */ > public AstRegion() { > } > > /** constructor with id */ > public AstRegion(java.lang.Character AstRegion) { > this.AstRegion = AstRegion; > } > > > > // Property accessors > /** > > */ > > public java.lang.Character getAstRegion () { > return this.AstRegion; > } > > public void setAstRegion (java.lang.Character AstRegion) { > this.AstRegion = AstRegion; > } > /** > > */ > > public AstCountry getAstCountry () { > return this.AstCountry; > } > > public void setAstCountry (AstCountry AstCountry) { > this.AstCountry = AstCountry; > } > /** > > */ > > public java.lang.Character getAstType () { > return this.AstType; > } > > public void setAstType (java.lang.Character AstType) { > this.AstType = AstType; > } > /** > > */ > > public java.lang.Character getAstDescription () { > return this.AstDescription; > } > > public void setAstDescription (java.lang.Character AstDescription) { > this.AstDescription = AstDescription; > } > /** > > */ > > public java.lang.Character getAstLastMaintUser () { > return this.AstLastMaintUser; > } > > public void setAstLastMaintUser (java.lang.Character AstLastMaintUser) { > this.AstLastMaintUser = AstLastMaintUser; > } > /** > > */ > > public java.lang.Character getAstLastMaintType () { > return this.AstLastMaintType; > } > > public void setAstLastMaintType (java.lang.Character AstLastMaintType) { > this.AstLastMaintType = AstLastMaintType; > } > /** > > */ > > public java.lang.Character getAstLastMaintJob () { > return this.AstLastMaintJob; > } > > public void setAstLastMaintJob (java.lang.Character AstLastMaintJob) { > this.AstLastMaintJob = AstLastMaintJob; > } > /** > > */ > > public java.lang.Integer getAstLastMaintTime () { > return this.AstLastMaintTime; > } > > public void setAstLastMaintTime (java.lang.Integer AstLastMaintTime) { > this.AstLastMaintTime = AstLastMaintTime; > } > /** > > */ > > public java.lang.Integer getAstLastMaintDate () { > return this.AstLastMaintDate; > } > > public void setAstLastMaintDate (java.lang.Integer AstLastMaintDate) { > this.AstLastMaintDate = AstLastMaintDate; > } > } > It seems that a CHAR(32...) should be translate to a String and not a Character java Type. > Thank > Etienne. > Montreal -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1411) Collection fetches and DISTINCT

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1411?page=c... ] Steve Ebersole closed HHH-1411. ------------------------------- Closing stale resolved issues > Collection fetches and DISTINCT > ------------------------------- > > Key: HHH-1411 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1411 > Project: Hibernate Core > Issue Type: Improvement > Components: query-criteria, query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Blocker > Fix For: 3.2.0.alpha1 > > > Collection fetches and DISTINCT currently do not return logical results, since the DISTINCT is applied at the database level. We need to recognize this scenario and perform the distincting in memory. -- 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1038) make 'auto' the default for hibernate.connection.release_mode

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1038?page=c... ] Steve Ebersole closed HHH-1038. ------------------------------- Closing stale resolved issues > make 'auto' the default for hibernate.connection.release_mode > ------------------------------------------------------------- > > Key: HHH-1038 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1038 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc 1 > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.1 rc2 > > Original Estimate: 4h > Remaining Estimate: 4h > > Currently, ConnectionReleaseMode defaults to ON_CLOSE, which was the legacy behavior (JDBC connections are cached until the Session is closed). Change this default to be the 'auto' behavior... -- 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

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