March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HHH-1466) better handling of Antlr exceptions

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1466?page=c... ] Steve Ebersole closed HHH-1466. ------------------------------- Closing stale resolved issues > better handling of Antlr exceptions > ----------------------------------- > > Key: HHH-1466 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1466 > Project: Hibernate Core > Issue Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.0.alpha1 > > > antlr.ANTLRException and its subclasses can cause issues due to serial version incompatibilities. In the QueryTranslator we should "decompose" any encountered ANTLRExceptions. -- 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-1520) with clause with implied joins within an explicit join

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1520?page=c... ] Steve Ebersole closed HHH-1520. ------------------------------- Closing stale resolved issues > with clause with implied joins within an explicit join > ------------------------------------------------------ > > Key: HHH-1520 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1520 > Project: Hibernate Core > Issue Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0.alpha1, 3.1.3 > > > A query like "from Customer c join c.orders o with o.shipment.date < ?" will parse correctly, but later blows up because the SQL is all hosed. In design, it was assumed that property-refs in the with clause always refer to the FromElement specified in the explicit join. > We should recognize this condition and throw an appropriate exception. -- 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-1003) PostgreSQL dialect uses sequence instead of identity for id="native"

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1003?page=c... ] Steve Ebersole closed HHH-1003. ------------------------------- Closing stale resolved issues > PostgreSQL dialect uses sequence instead of identity for id="native" > -------------------------------------------------------------------- > > Key: HHH-1003 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1003 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Hibernate 3.0.5 > PostgreSQL 8.0.3 > Reporter: Simone Bordet > > The class org.hibernate.dialect.PostgreSQLDialect overrides (incorrectly, I think, for PostgreSQL 8 at least) the method getNativeIdentifierGeneratorClass(), returning SequenceGenerator.class. > Since PostgreSQL supports IdentityGenerator, via serial and bigserial data types, it would be cool to have it supported out of the box from Hibernate. > Note that the behavior of the base class org.hibernate.dialect.Dialect is already what is needed; that is, there is no need to override getNativeIdentifierGeneratorClass() in PostgreSQLDialect. > I have no idea if this is done for compatibility with older PostgreSQL versions; if so, maybe a solution like OracleDialect/Oracle9Dialect may be used. > Thanks ! -- 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-1112) StaleObjectStateException not being thrown when expected

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1112?page=c... ] Steve Ebersole closed HHH-1112. ------------------------------- Closing stale resolved issues > StaleObjectStateException not being thrown when expected > -------------------------------------------------------- > > Key: HHH-1112 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1112 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Windows XP with JDK 1.4.2 > Hibernate 3.0.5 > Oracle database 9i > Reporter: Virinder Singh > > Hi, > We use modify_timestamp as our managed versioning. > We have a scenario in a web application where we do the following steps: > (1) Retrieve event with id="1234". (called eventDTO1 which reads its values from event POJO) (modify timestamp say 1 pm) > (2) Retrieve another event with same id="1234" (called eventDTO2 which reads its values from event POJO) (modify timestamp say 1:10 pm) > (3) Make some updates in presentation layer to some attributes of eventDTO2 and send it to persistence layer for update. Persistence layer retrieved event POJO and updated its attributes from eventDTO2. Everything is updated succesfully and modify timestamp is updated to current time (say 1:20 pm) > (4) Now make some updates to eventDTO1 and send it to persistence layer, persistence layer retrieved event POJO and updated its attributes from eventDTO1. we expected to see StateObjectStateException but everything gets updated successfully and modify_timestamp is updated to say 1:30 pm (which was when we did update for event) > When I look at the reason why the update went through succesfully, I found that the following query was used: > 2005-10-28 13:55:15,969 [main] DEBUG org.hibernate.SQL - update SUBMISSIONS set MODIFY_TIMESTAMP=?, MODIFY_ID=? where ID=? and MODIFY_TIMESTAMP=? > The actual query with values (in pseudo-code) looks like this: > update SUBMISSIONS set MODIFY_TIMESTAMP="1:30 pm", modify_id='ABCD' where is='1234' and MODIFY_TIMESTAMP="1:20 pm"; > (this query will always succeed since the value of MODIFY_TIMESTAMP used in where clause is value stored in database (previousState) and not currentState which will be set from presentation layer) > The MODIFY_TIMESTAMP that we should expect to be used in the where clause is the one held in eventDTO1 (which was 1:10 pm) > But the value that was used in MODIFY_TIMESTAMP in where clause was 1:20 pm and not 1:10 pm which would have triggered StaleObjectStateException. 1:20 pm was time when eventDTO2 in step 3 was successfully updated. I found these values reliably by using p6spy. > Hibernate should be using the modify_timestamp value that is coming from presentation layer and not the current modify_timestamp value stored in database. > I am using following attributes in all in hbm xml files: > <class > name="gov.ca.doj.sins.riss.model.Submission" > table="SUBMISSIONS" select-before-update="true" dynamic-update="true" optimistic-lock="version" > > > ... > ... > <timestamp name="modifyTimestamp" column="MODIFY_TIMESTAMP" /> > Thanks in advance, > -Virinder. > -- 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-1144) Implement naming convention for temporary test failures

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1144?page=c... ] Steve Ebersole closed HHH-1144. ------------------------------- Closing stale resolved issues > Implement naming convention for temporary test failures > ------------------------------------------------------- > > Key: HHH-1144 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1144 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Christian Bauer > Assignee: Steve Ebersole > Priority: Trivial > Fix For: 3.1 > > > >> - How do we deal with failing tests in the future? Ryan mentioned that there is a mechanism already in place for other projects, something like a list where developers can maintain tests that are allowed to fail. > > > > How about just having FailureExpected as part of the signature until the test is a passing test ? > > > > testSubselectFailureExpected() - directly visible and collectable via a simple search. > This seems like the best approach. Steve, can you rename the current tests that are allowed to fail in that way? Thanks -- 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-1235) Is Composition possible with Hibernate?

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1235?page=c... ] Steve Ebersole closed HHH-1235. ------------------------------- Closing stale resolved issues > Is Composition possible with Hibernate? > --------------------------------------- > > Key: HHH-1235 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1235 > Project: Hibernate Core > Issue Type: Task > Components: core > Affects Versions: 3.0.5 > Environment: Oracle 9i,Hibernate 3.0.5, Eclipse 3.1 > Reporter: chaitanya sanjay karmarakr > Original Estimate: 24h > Remaining Estimate: 24h > > I have a POJO Client.java.I want this class to compose an object of another class ClientAddress; which is a POJO class too. A *.hbm.xml is present for both. > package com.hibernate.tutorial.classes; > public class Client{ > private Long clientNo; > private String clientName; > private Long clientOfficeId; > private String clientStatusCode; > private String clientFundCode; > > private ClientAddressUsage clientAddressUsagePOC; > public ClientAddressUsage getClientAddressUsage() { > return clientAddressUsage; > } > public void setClientAddressUsage(ClientAddressUsage clientAddressUsage) { > this.clientAddressUsage = clientAddressUsage; > } > > > public String getClientFundCode() { > return clientFundCode; > } > public void setClientFundCode(String clientFundCode) { > this.clientFundCode = clientFundCode; > } > public String getClientName() { > return clientName; > } > public void setClientName(String clientName) { > this.clientName = clientName; > } > public Long getClientNo() { > return clientNo; > } > public void setClientNo(Long clientNo) { > this.clientNo = clientNo; > } > public Long getClientOfficeId() { > return clientOfficeId; > } > public void setClientOfficeId(Long clientOfficeId) { > this.clientOfficeId = clientOfficeId; > } > public String getClientStatusCode() { > return clientStatusCode; > } > public void setClientStatusCode(String clientStatusCode) { > this.clientStatusCode = clientStatusCode; > } > } > Now, for acheiving composition is the Client.hbm.xml correct: > <?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> > <class name="com.tutorial.hibernate.classes.ClientPOC" table="CLIENT_POC" > > <composite-id > > <key-property name="clientNo" type="java.lang.Long" column="CLIENT_NO"/> > <key-property name="clientOfficeId" type="java.lang.Long" column="CLIENT_OFFICE_ID"/> > </composite-id> > <property name="clientName" type="java.lang.String"> > <column name="CLIENT_NAME" length="40" /> > </property> > <property name="clientStatusCode" type="java.lang.String"> > <column name="CLIENT_STATUS_CODE" length="1" /> > </property> > <property name="clientFundCode" type="java.lang.String"> > <column name="CLIENT_FUND_CODE" length="3" /> > </property> > <property name="clientAddressUsagePOC" type="java.lang.Object" access="com.tutorial.hibernate.classes.ClientAddressUsagePOC" > > </property> > > </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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1000) varchar(xxx char) not supported on Oracle8i

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1000?page=c... ] Steve Ebersole closed HHH-1000. ------------------------------- Closing stale resolved issues > varchar(xxx char) not supported on Oracle8i > ------------------------------------------- > > Key: HHH-1000 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1000 > Project: Hibernate Core > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.1 rc 1 > > Original Estimate: 5m > Remaining Estimate: 5m > > Through its inheritence from Oracle9Dialect, OracleDialect currently tries to use the varchar(xxx char) form for column specificattions. That form is not supported on Oracle8i. -- 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-1091) Can't write transparent CurrentSessionContext for BMT

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1091?page=c... ] Steve Ebersole closed HHH-1091. ------------------------------- Closing stale resolved issues > Can't write transparent CurrentSessionContext for BMT > ----------------------------------------------------- > > Key: HHH-1091 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1091 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Christian Bauer > Assignee: Steve Ebersole > Priority: Blocker > Fix For: 3.1 rc3 > > > The purpose of the CurrentSessionContext was transparent client code for at least TLS and BMT scenario: > getCurrentSession().beginTransaction(); > // do stuff > getCurrentSession.getTransaction().commit(); > This is not possible with the current implementations. JTASessionContext only works in a CMT environment, or requires the user to begin and end a JTA transaction through the JTA API. The code above does not work for BMT. > A custom BMTSessionContext can not take care of this issue, e.g. by starting a JTA transaction for the user when he first calls getCurrentSession(). The user is then not able to call getTransaction().commit(), but would also have to use the JTAPI to end the transaction (Hibernate Transaction API is no-op of someone else started the JTA tx). One way to hack this is a custom Transaction/TransactionFactory implementation that always commits a JTA transaction, no matter who started it. > In other words, the new current session context feature is only useful because it incorporates the TLS stuff into Hibernate. It does however not provide any real portability. We need to clean up this mess before we finalize 3.1. -- 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-964) ORA-00936 with joined subclass / Oracle

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-964?page=co... ] Steve Ebersole closed HHH-964. ------------------------------ Closing stale resolved issues > ORA-00936 with joined subclass / Oracle > --------------------------------------- > > Key: HHH-964 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-964 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 beta 2 > Environment: Hibernate 3.1 beta 3, Oracle 9i Release 2 (9.2.0.1) > Reporter: Heiko Hüter > Assignee: Steve Ebersole > Priority: Blocker > Fix For: 3.1 rc 1 > > Attachments: testCase.zip > > > if i do a delete from SubObjekt where propertyA='1234' bulk -delete i get an ORA-00936 error. The entity SubObjekt is a joined-subclass of the type SuperObjekt. The generated sql looks like : > insert into HT_SUB_OBJEKT select del.ID as ID from SYSADM5.SUB_OBJEKT del, SYSADM5.SUPER_OBJEKT del_1_ where and del.ID=del_1_.IDPROPERTY_A='1234' > The problem is the unnecessary and directly after the where clause. > the attached zip files contains a runnable junit test for the problem. You just need to have an running oracle instance with user TEST (password TEST) and granted roles CONNECT, RESOURCE > I tested the existence of this bug with 3.1 beta 2 and 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

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1051) "Compiled" native SQL queries are not cached

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1051?page=c... ] Steve Ebersole closed HHH-1051. ------------------------------- Closing stale resolved issues > "Compiled" native SQL queries are not cached > -------------------------------------------- > > Key: HHH-1051 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1051 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.0 alpha > Reporter: Gavin King > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.1 rc3 > > > Currently, a new SQLLoader is instantiated every time we execute a SQL query. This means we re-parse the SQL string many times. > We should cache the loader at the SessionFactory level, since it is threadsafe. -- 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