March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HHH-1308) Session.createFilter(...).iterate() results in bogus column names for result set extraction

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1308?page=c... ] Steve Ebersole closed HHH-1308. ------------------------------- Closing stale resolved issues > Session.createFilter(...).iterate() results in bogus column names for result set extraction > ------------------------------------------------------------------------------------------- > > Key: HHH-1308 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1308 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.1.1 > > > The issue was that looking up the FilterQueryPlan for iterate() was broken. It actually looked up the non-scalar plan. -- 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-994) Sybase/SQLServer support for temporary tables

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-994?page=co... ] Steve Ebersole closed HHH-994. ------------------------------ Closing stale resolved issues > Sybase/SQLServer support for temporary tables > --------------------------------------------- > > Key: HHH-994 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-994 > Project: Hibernate Core > Issue Type: Patch > Components: core > Affects Versions: 3.1 beta 2 > Environment: CVS HEAD, SQLServer 2000 > Reporter: Nathan Moon > Assignee: Steve Ebersole > Fix For: 3.1 rc 1 > > Attachments: SQLServerDialect.patch > > > SQLServerDialect needs to support temporary tables in order for deletes on joined-subclasses to work. This patch adds support for temporary tables to SQLServerDialect. I'm not a Sybase user, so I couldn't test to see if this could be put into SybaseDialect instead, but that may be the case. -- 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-1518) Guarentee LockMode behaviors

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1518?page=c... ] Steve Ebersole closed HHH-1518. ------------------------------- Closing stale resolved issues > Guarentee LockMode behaviors > ---------------------------- > > Key: HHH-1518 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1518 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0.alpha1 > > > The current thought process behind applying lock modes is to simply assume that the given database supports such locking-level/isolation. In the case where a database does not, the effect is that we "gracefully" fall back to a lower LockMode. > Consider HSQLDB as an example. It does not support any isolation level other than READ_UNCOMMITTED. If a user attempts a session.lock( myEntity, LockMode.UPGRADE ) the net effect on HSQLDB is that essentially nothing happens; no form of write lock is acquired in the database. > The other concern is databases which do not support write lock acqusition through selects (i.e., no "SELECT ... FOR UPDATE" syntax or variation). The only way to acquire write locks on these databases is to perform a write. -- 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-609) Adds substr to PostgreSQL dialect

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-609?page=co... ] Steve Ebersole closed HHH-609. ------------------------------ Closing stale resolved issues > Adds substr to PostgreSQL dialect > --------------------------------- > > Key: HHH-609 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-609 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Environment: Hibernate 2/3, PostgreSQL 7.4.x/8.0.x > Reporter: Michael O'Cleirigh > Fix For: 3.1 beta 1 > > Original Estimate: 1h > Remaining Estimate: 1h > > Currently in Hibernate 2/3 its impossible to execute the following HQL when targeting the PostgreSQL database: > "select substr (a.postalCode, 1, 3) from Address a" > By adding the substring to the PostgreSQL dialect this query works as desired. > For some reason using this variant: > "select substr (postalCode, 1, 3) from Address" > causes all persistent instances from Address to be loaded (as if "from Address" had been called) > For Hibernate2 the addition to the PostgreSQL dialect is: > registerFunction ("substr", > new StandardSQLFunction (Hibernate.STRING); > For Hibernate3 the addition to the PostgreSQL dialect is: > registerFunction ("substr", > new StandardSQLFunction ("substr", Hibernate.STRING); -- 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-144) reverse engineering - identifier attribute in the id element is hardcoded to "assigned"

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-144?page=co... ] Steve Ebersole closed HBX-144. ------------------------------ Closing stale resolved issues > reverse engineering - identifier attribute in the id element is hardcoded to "assigned" > --------------------------------------------------------------------------------------- > > Key: HBX-144 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-144 > Project: Hibernate Tools > Issue Type: Bug > Components: reverse-engineer > Affects Versions: 3.0alpha2 > Environment: tools 3.0 alpha1 > hibernate 3.0 rc1 > eclipse 3.1M4 > Reporter: hsalameh > Fix For: 3.1beta1 > > > in the reverse engineering tool, the identifier attribute of the id element is at the moment hardcoded to the value "assigned" > this should be changed so that it detects the type of primary key in the table and act accordingly. for example, if the primary key was of type IDENTITY, the type should be "native". > there might be other situations, but i am not very familiar with them. -- 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-1592) allow SelectGenerator to use a defined natural-id (if one)

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1592?page=c... ] Steve Ebersole closed HHH-1592. ------------------------------- Closing stale resolved issues > allow SelectGenerator to use a defined natural-id (if one) > ---------------------------------------------------------- > > Key: HHH-1592 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1592 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0 cr1 > > > Currently SelectGenerator requires that the user configure it with a property name representing a unique key. Would be nice if this was not necessary in the case where they have mapped a <natural-id/> since a natural-id already fulfills that role. -- 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-617) Reverse engineering uses hibernate type="int" in hbm.xml instead of "integer" for primary key column

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-617?page=co... ] Steve Ebersole closed HBX-617. ------------------------------ Closing stale resolved issues > Reverse engineering uses hibernate type="int" in hbm.xml instead of "integer" for primary key column > ---------------------------------------------------------------------------------------------------- > > Key: HBX-617 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-617 > Project: Hibernate Tools > Issue Type: Bug > Affects Versions: 3.1beta4 > Environment: Hibernate 3.0, SQL Server 2000, jtds-1.2 driver > Reporter: Stefanie Liepmann > Priority: Minor > Fix For: 3.1.beta5 > > > I have a table in SQL Server 2000 with the following properties: > Name: Case_ID > DataType: int > Length: 4 > Allow Nulls: No > It is the primary key on the table and it uses the identity generator. > I created a hibernate.reveng.xml file and edit it in the Hibernate Reverse Engineering Editor. > The code for the file looks some like this: > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" > > <hibernate-reverse-engineering> > <table-filter match-catalog="DBName" match-schema="dbo" > match-name="Study" /> > <table catalog="DBName" schema="dbo" name="Study"> > <primary-key> > <generator class="identity"></generator> > </primary-key> > <column name="Column2" jdbc-type='' /> >  > </table> > </hibernate-reverse-engineering> > When it generates the hbm.xml file the code looks like this: > <id name="caseId" type="int"> > <column name="Case_ID" /> > <generator class="identity"></generator> > </id> > Therefore when I generate the .java code, the Java datatype is a primitive "int". This is not desired since the primary key column should be an object (java.lang.Integer in this case) and not a primitive. Shouldn't the type in the hbm.xml file default to "integer". I know that I can "fix" this behaviour by mapping the datatypes in the "Type Mappings" tab, but I wonder if this is what is intended and if it will frustrate other users. I also noticed a similar problem with the short datatype in that I had to explicitly use "java.lang.Short" when the column allows nulls. Otherwise the hbm2java did not map it correctly. If I am wrong about this, please let me know. -- 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-593) Public API To Determine if an object is Unsaved

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-593?page=co... ] Steve Ebersole closed HHH-593. ------------------------------ Closing stale resolved issues > Public API To Determine if an object is Unsaved > ----------------------------------------------- > > Key: HHH-593 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-593 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: brian blount > > Provide an API to determine if an entity has been saved to the database yet. As a workaround, if the default id scheme is used, I can check to see if the id is null. However, I would rather tie into hibernate's code to do the check. -- 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-1011) Make disconnect/reconnect of a Session implicit

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1011?page=c... ] Steve Ebersole closed HHH-1011. ------------------------------- Closing stale resolved issues > Make disconnect/reconnect of a Session implicit > ----------------------------------------------- > > Key: HHH-1011 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1011 > Project: Hibernate Core > Issue Type: Improvement > Reporter: Christian Bauer > Assignee: Steve Ebersole > Fix For: 3.1 rc 1 > > > Removal of the disconnect() and reconnect() methods and automatic disconnect and reconnect on commit/rollback and beginTransaction. -- 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-653) Insert on an optional joined table with non insertable properties

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-653?page=co... ] Steve Ebersole closed HHH-653. ------------------------------ Closing stale resolved issues > Insert on an optional joined table with non insertable properties > ----------------------------------------------------------------- > > Key: HHH-653 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-653 > Project: Hibernate Core > Issue Type: Bug > Components: core > Environment: JDK 1.4.2_08, Oracle JDBC driver 9.2.0.4.0 > Reporter: Emmanuel Bourg > Attachments: join-insert.patch, joined-table-persist.patch > > > Hibernate generates an INSERT on an optional joined table even if the properties of this table are flagged as not insertable. This leads to a database error if the joined table is read only. > For example with the following mapping: > <class name="Cat" table="CAT"> > <id name="id" column="CAT_ID" type="int"> > <generator class="sequence"> > <param name="sequence">CAT_SEQ</param> > </generator> > </id> > <join table="CAT_INFO" optional="true"> > <key column="CAT_ID" /> > <property name="tamed" column="TAMED" type="boolean" insert="false" update="false"/> > </join> > </class> > Hibernate will generate two queries, the first one to insert in the CAT table, and the second on to insert in the CAT_INFO table, even if the "tamed" properties is not persisted. -- 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