April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3227) Oracle's connect by syntax is mishandled when used with Filter

by Kyrill Alyoshin (JIRA)

Oracle's connect by syntax is mishandled when used with Filter -------------------------------------------------------------- Key: HHH-3227 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3227 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.5 Environment: Hibernaet 3.2.5.GA, Oracle 10g. Reporter: Kyrill Alyoshin Basically, I have a filter definition on a class (via annotation), here it is: @Filter(name = "limitInvoicesByAccountHolderHierarchy", condition = "CHRG_ACCT_ID in (" + "select ca1.chrg_acct_id from cv_chrg_acct ca1 " + "inner join cv_org_unit og1 on ca1.acct_hldr_id = og1.org_unit_id " + "where og1.org_unit_id in (" + "select og2.org_unit_id from cv_org_unit og2 " + "start with og2.org_unit_id = :root " + " connect by prior og2.org_unit_id = og2.hier_par_org_unit_id" + ')' + ')' It contains Oracle's "connect by" clause. Here is the SQL statement that Hibernate generates when trying to query invoices with the filter enabled: Hibernate: /* from Invoice */ select invoice0_.inv_id as inv1_31_, ...... from CV_INV invoice0_ where invoice0_.CHRG_ACCT_ID in ( select ca1.chrg_acct_id from cv_chrg_acct ca1 inner join cv_org_unit og1 on ca1.acct_hldr_id = og1.org_unit_id where og1.org_unit_id in ( select og2.org_unit_id from cv_org_unit og2 invoice0_.start invoice0_.with og2.org_unit_id = ? invoice0_.connect by invoice0_.prior og2.org_unit_id = og2.hier_par_org_unit_id ) ) Even though the documentation states that the condition of the filter is pure SQL (which is great!), it still does not pass SQL verbatim but is actually trying to pre-process the following words: start, with, connect, prior. Is there an easy work around to make Oracle10gDialect recognize these words? Thanks a lot for looking into this! -- 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

14 years

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2402) HQL generates inner join when selecting a specific attribute that is linked to another entity

by Peter Mutsaers (JIRA)

HQL generates inner join when selecting a specific attribute that is linked to another entity --------------------------------------------------------------------------------------------- Key: HHH-2402 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2402 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: Oracle 9i, affects ONLY version 3.2.2, was still working OK in version 3.2.1 and before. Reporter: Peter Mutsaers Priority: Critical Mapping (note the lazy='false', it is essential to cause the problem): <class name='Currency' lazy='false'> .... </class> <class name='Asset'> <id name='id' ... </id> <many-to-one name='currency' class='Currency' fetch='select'/> </class> The following HQL query: "select a.id, a.currency from Asset a" used to generate a query on the Asset table, and subsequently generates separate queries on the Currency table. Since version 3.2.2, this generates an inner join on Asset with Currency. Now many Assets may have a NULL currency, so we do not get all records anymore! This breaks logic and queries all over the place for us. We can't go back to 3.2.1 due to other bugs that had been solved in 3.2.2. The query "from Asset a" still works OK and as before, i.e. it makes the select only on the Asset table and afterwards fetches the Currency with individual selects. I fear that an optimization has been made that has this negative side effect. -- 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

14 years

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3510) Sybase - Timestamp not being translated to the built-in database function

by Juraci Paixao Krohling (JIRA)

Sybase - Timestamp not being translated to the built-in database function ------------------------------------------------------------------------- Key: HHH-3510 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3510 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: Branch_3_2_4_SP1_CP and Sybase 15 Reporter: Juraci Paixao Krohling Test Case: ComponentTest#testComponentQueries Hibernate query "from Employee e where e.person = ('steve', current_timestamp)" should have translated "current_timestamp" to "getdate()" [1]: 14:49:11,087 DEBUG SQL:424 - select employee0_.ID as ID1_, employee0_.HIRE_DATE as HIRE2_1_, employee0_.name as name1_, employee0_.dob as dob1_, employee0_.value1 as value5_1_, employee0_.value2 as value6_1_ from T_EMP employee0_ where employee0_.name='steve' and employee0_.dob=current_timestamp 14:49:11,535 WARN JDBCExceptionReporter:77 - SQL Error: 207, SQLState: ZZZZZ 14:49:11,536 ERROR JDBCExceptionReporter:78 - Invalid column name 'current_timestamp'. [1] SybaseDialect, line 58: registerFunction( "current_timestamp", new NoArgSQLFunction("getdate", Hibernate.TIMESTAMP) ); -- 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

14 years

4
8
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

14 years

1
1
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

14 years

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

14 years

2
8
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

14 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2426) Misleading logging messages when using ThreadLocalSessionContext

by Don Smith (JIRA)

Misleading logging messages when using ThreadLocalSessionContext ---------------------------------------------------------------- Key: HHH-2426 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2426 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Reporter: Don Smith Priority: Minor The log messages printed out by TransactionFactoryFactory and SettingsFactory are misleading when using ThreadLocalSessionContext: 2007-02-09 21:49:58,581 INFO [org.hibernate.transaction.TransactionFactoryFactory:info] Using default transaction strategy (direct JDBC transactions) 2007-02-09 21:49:58,588 INFO [org.hibernate.transaction.TransactionManagerLookupFactory:info] No TransactionManagerLookup Configured (in JTA environment, use of read-write or transactional second-level cache is not recommended) 2007-02-09 21:49:58,590 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic flush during beforeCompletion(): disabled 2007-02-09 21:49:58,591 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic session close at end of transaction: disabled This does not indicate that sessions will be closed after commit, which is the behavior when using ThreadLocalSessionContext. -- 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

14 years

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-682) @ForeignKey override of @MappedSuperclass

by Christian Bauer (JIRA)

@ForeignKey override of @MappedSuperclass ----------------------------------------- Key: ANN-682 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-682 Project: Hibernate Annotations Issue Type: New Feature Components: binder Reporter: Christian Bauer Put this @ManyToOne in a @MappedSuperclass: @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "CREATED_BY_USER_ID", nullable = false) // Ideally this foreign key should be ON DELETE SET NULL, however... // Hibernate can't rename these so subclasses would get the same FK constraint name. This doesn't // work, so we need to let Hibernate create a random identifier for these. We could fix this in the // DatabaseObjects.hbm.xml file but we can't even address it because the name is random. This sucks. // So we do a manual SET NULL|DEFAULT when userHome.remove() is called. // @org.hibernate.annotations.ForeignKey(name = "FK_WIKI_NODE_CREATED_BY_USER_ID") protected User createdBy; Now all subclasses get that foreign key constraint name in the database catalog, which isn't possible - constraint names have to be unique. -- 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

14 years

6
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3976) NPE when eager fetching joined component with native SQL query

by Franz Allan Valencia See (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-3976 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3976 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.2.0.ga Reporter: Franz Allan Valencia See Priority: Critical Given a Hibernate Mapping with formula and named sql query, When accessing named sql query, NPE is thrown. This is basically a duplicae of HHH-2225. But since I cannot edit that to change it's Priority, I created a dupe. Feel free to close this if HHH-2225 has been edited to a higher priority. IMHO, it should be of a higher priority because AFAIK there are no decent workaround for this. -- 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

14 years

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010