April 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2317) CGLIB unable to lazy load classes in diff. classloader than hibernate jars

by Jason Novotny (JIRA)

CGLIB unable to lazy load classes in diff. classloader than hibernate jars --------------------------------------------------------------------------- Key: HHH-2317 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Reporter: Jason Novotny Please see http://forum.hibernate.org/viewtopic.php?p=2334617#2334617 for more details and possible fix -- 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

16 years, 11 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3229) Make cascade rules more transparent/explicit/deterministic

by Chris Bredesen (JIRA)

Make cascade rules more transparent/explicit/deterministic ---------------------------------------------------------- Key: HHH-3229 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.6, 3.2.5, 3.2.4.sp1 Reporter: Chris Bredesen Cascade rules are prone to different behavior based on the order in which properties appear in mapping XML. It is possible that an unexpected TransientObjectException may arise from certain operations when an object graph with circular references is merged (and possibly persisted/updated, etc). For example, if a transient instance is reachable through more than once path from a root entity, it is not clear whether operations will be cascaded to it. The order in which the properties are mapped plays a part in determining cascade paths, but the rules are not documented. Possible resolutions include: 1. Documenting the rules so that a programmer can make educated decisions about mapping. 2. Enhancing the algorithm such that order no longer matters and the rules are deterministic. 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

16 years, 11 months

6
12
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-329) Workers ThreadPools breaks ThreadLocals

by Grégoire Rolland (JIRA)

Workers ThreadPools breaks ThreadLocals --------------------------------------- Key: HSEARCH-329 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-329 Project: Hibernate Search Issue Type: Bug Components: directory provider Affects Versions: 3.1.0.GA Reporter: Grégoire Rolland When Implementing multi-domains (multi-databases) FSDirectory based on thread local (to get the thread environment, database name, etc...), the threadpool used by workers "forgot" the thread local variables on the second call (for searching, indexing). Works great with 3.0.1 release, but not with 3.1.0.GA. -- 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

16 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3095) Invalid queries when using subclasses and one-to-many associations

by Sebastien Blind (JIRA)

Invalid queries when using subclasses and one-to-many associations ------------------------------------------------------------------ Key: HHH-3095 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3095 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, bug identified on sybase Reporter: Sebastien Blind Priority: Blocker Attachments: src-cat.zip This bug report builds on top of the topic found in the forum at http://forum.hibernate.org/viewtopic.php?t=977453 Basically, there seems to be an issue in the way hibernate treats a collections of objects that extend a base class. The attached example has: a Cat class a DomesticCat class (extends Cat) a Cage class (can contain multiple DomesticCat) The generated SQL is below - the filter cats0_.CAGE_ID=? should really be cats0_1_.CAGE_ID=? select cats0_.CAGE_ID as CAGE3_1_, cats0_.CAT_ID as CAT1_1_, cats0_.CAT_ID as CAT1_0_0_, cats0_1_.CAGE_ID as CAGE2_2_0_ from CAT cats0_ inner join DCAT cats0_1_ on cats0_.CAT_ID=cats0_1_.CAT_ID where cats0_.CAGE_ID=? As of now, I am not aware of any configuration that would work around this problem. Please let me know if you know otherwise. Thanks, Sebastien -- 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

16 years, 11 months

2
1
0 / 0

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

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-465?page=co... ] Steve Ebersole commented on HHH-465: ------------------------------------ In the interest of completeness, it is actually the SQL-2003 spec which introduces NULLS FIRST | NULLS LAST. Also, it does not define the "sort key" as simply as [COLUMN NAME]. In SQL-92 it was the case that a sort-key could only be (a) column name or (b) integer literal (indicating the select-clause position). For SQL-2003 (and SQL-99), the full definition of sort key is: <sort key> ::= <value expression> essentially anything that resolves to a value (see http://savage.net.au/SQL/sql-2003-2.bnf.html#sort%20key for details) The difficulty here is if we are going to support SQL-2003 then we need to support its full breadth. Which implies an audit to see what databases fully comply with the various SQL-2003 defined compatibility levels. > 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1873) Query the hibernate version through the API

by Paul Benedict (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873?page=c... ] Paul Benedict commented on HHH-1873: ------------------------------------ I could see exposing the implementation version of the Session. > Query the hibernate version through the API > ------------------------------------------- > > Key: HHH-1873 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: Mark Grand > Priority: Minor > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > I am building a tool that will work with hibernate. Though this tool will be used with hibernate, I want it to work with whatever version of hibernate my users select. Making this work with future versions of hibernate will be eaiser if there is something in the API that says what the version of hibernate is. -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1873) Query the hibernate version through the API

by Ben Groeneveld (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873?page=c... ] Ben Groeneveld commented on HHH-1873: ------------------------------------- Yes, understand the problem (the compiler is following the non-intuitive spec) and am suggesting a permanent workaround. For example, I have come across this pattern as a solution. Maybe it will work for you. public static class StaticFinals { public static String dynamic(String s) { return s; } public static int dynamic(int i) { return i; } // TODO implement methods for each primitive type } public static class ExampleProgram { public static final String MY_STATIC_STRING = StaticFinals.dynamic("Might change"); public static final int MY_STATIC_INT = StaticFinals.dynamic(42); } > Query the hibernate version through the API > ------------------------------------------- > > Key: HHH-1873 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: Mark Grand > Priority: Minor > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > I am building a tool that will work with hibernate. Though this tool will be used with hibernate, I want it to work with whatever version of hibernate my users select. Making this work with future versions of hibernate will be eaiser if there is something in the API that says what the version of hibernate is. -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1873) Query the hibernate version through the API

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873?page=c... ] Steve Ebersole commented on HHH-1873: ------------------------------------- That's what the Java compiler does in terms of static fields. Even adding a method on Environment will *not* suffice if by that you mean something like: public static String getVersion() { return VERSION; } My (limited) testing showed that compilers were smart enough to inline the value of VERSION into the caller of getVersion() in these cases as well. AFAIK, the only real option around that here is to have a non-static definition of the version, the question being from where to make that available. Of course in the interim you ca n use reflection to get this value which would be safe from compiler inlining... > Query the hibernate version through the API > ------------------------------------------- > > Key: HHH-1873 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1873 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Reporter: Mark Grand > Priority: Minor > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > I am building a tool that will work with hibernate. Though this tool will be used with hibernate, I want it to work with whatever version of hibernate my users select. Making this work with future versions of hibernate will be eaiser if there is something in the API that says what the version of hibernate is. -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-892) HQL parser does not resolve alias in ORDER BY clause

by Kevin Kelley (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-892?page=co... ] Kevin Kelley commented on HHH-892: ---------------------------------- I've hit a wall with this issue. I have a lengthy query (generated by Hibernate 3.3.1 and Annotations 3.4.0) with a bunch of joins that fails (on DB2 v9.1) when trying to order by a particular column. The generated SQL uses the real table name and column name. ... order by T_TMPLT_ELMNT_PRXY.SEQUENCE_NUM asc If I comment out the @OrderBy annotation it runs fine. I then manually ran the SQL, with the order by clause, and replaced the table name with the table alias (this ran fine) ... order by elements0_1_.SEQUENCE_NUM asc And finally I ran the same query with just the column alias in the order by clause and this also ran fine. ... order by SEQUENCE13_79_3_ asc This appears to be a bug in hibernate as the SQL is entirely generated by hibernate (based on standard annotations) and will run fine is using the aliases. It does seem strange that using the FQN of the column doesn't work from the database perspective. Since I can't seem to sort the objects directly on the database, I'll use a TreeSet to reorder the objects based on the sequence number; it works, it's just not nearly as effecient. I would be ecstatic if there was a fix for this. > HQL parser does not resolve alias in ORDER BY clause > ----------------------------------------------------- > > Key: HHH-892 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-892 > Project: Hibernate Core > Issue Type: Bug > Components: query-hql > Affects Versions: 3.0.5 > Environment: Hibernate 3.0.5, MySQL, Tomcat > Reporter: Guido Laures > Priority: Minor > > When using an alias for an ORDER BY clause this is not always correctly resolved. Example: > SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY mySum > does not work because "mySum" is not resolved in the ORDER BY clause which results in an exception telling that mySum is an unknown column. > Workaround (not to say "hack") is using: > SELECT SUM(A.x) AS mySum FROM MyClass AS A GROUP BY A.y ORDER BY col_0_0_ -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-790) ImmutableTest leaves an active transaction

by Juraci Paixao Krohling (JIRA)

ImmutableTest leaves an active transaction ------------------------------------------ Key: ANN-790 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-790 Project: Hibernate Annotations Issue Type: Patch Environment: PostgreSQL 8.2.3 and Annotations from trunk Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling Attachments: ImmutableTest.java.diff ImmutableTest leaves an active transaction and makes PostgreSQL waits until it is finished (which never occurs). The attached patch fixes it. -- 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

16 years, 11 months

1
3
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 April 2009