November 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Updated: (HHH-1767) read-only cache for immutable collection causes unnecessary warning

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1767?page=all ] Steve Ebersole updated HHH-1767: -------------------------------- Fix Version: 3.2.1 Assign To: Steve Ebersole > read-only cache for immutable collection causes unnecessary warning > ------------------------------------------------------------------- > > Key: HHH-1767 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1767 > Project: Hibernate3 > Type: Patch > Components: core > Versions: 3.1.3 > Reporter: Alex Burgel > Assignee: Steve Ebersole > Priority: Trivial > Fix For: 3.2.1 > Attachments: SessionFactoryImpl.patch > > > SessionFactoryImpl always says collections are mutable when calling the CacheFactory, even if the mapping file says otherwise. this causes a warning in the CacheFactory -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1718) Have multiple bag fetches revert to subselect fetching for all but one of the bags

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718?page=all ] Steve Ebersole updated HHH-1718: -------------------------------- Fix Version: 3.2.2 (was: 3.2.1) not going to get done for 3.2.1 > Have multiple bag fetches revert to subselect fetching for all but one of the bags > ---------------------------------------------------------------------------------- > > Key: HHH-1718 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718 > Project: Hibernate3 > Type: Improvement > Components: query-hql, query-criteria, core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.2 > > > Follow on to HHH-1413. Multiple bag fetches were simply disallowed as the resolution to that particular case in the interest of working around that issue. > The correct longer term solution is to not fetch all the bags at once, ideally reverting to subselect fetching for all but one of the bags. -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1499) use subselect fetching for collection join fetches with DISTINCT or firstResult/maxRows

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1499?page=all ] Steve Ebersole updated HHH-1499: -------------------------------- Fix Version: 3.2.2 (was: 3.2.1) not going to get done for 3.2.1 > use subselect fetching for collection join fetches with DISTINCT or firstResult/maxRows > --------------------------------------------------------------------------------------- > > Key: HHH-1499 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1499 > Project: Hibernate3 > Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.2 > > > As a follow on to HHH-1411and HHH-1412... > Both of those above were actually resolved by handling the DISTINCT-ion and/or firstResult/maxRows *in memory*. A better solution is to not honor the join fetch in these cases, perform the requested operation, and then get the requested join fectehd collections through subselect fetches. > As is, this would work as long as the collections have subselect fetching enabled in metadata, but would actually use immediate fetching (n+1) for any collections not defining subselect fetching in metadata. This is due to the way PersistenceContext.initializeNonLazyCollections() currently works. -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1050) HQL Unions

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1050?page=all ] Steve Ebersole updated HHH-1050: -------------------------------- Fix Version: (was: 3.2.1) On hold until after translator and grammar changes are complete > HQL Unions > ---------- > > Key: HHH-1050 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1050 > Project: Hibernate3 > Type: New Feature > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > > > Add the ability to define unions in HQL. Support will be initially limited to only: > 1) scalar queries : select id from Animal union select id from Car > 2) the same entity : from Animal where ... union from Animal where ... > Support both UNION and UNION ALL -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-695) Ability to specify cascading in HQL delete

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-695?page=all ] Steve Ebersole updated HHH-695: ------------------------------- Component: query-hql (was: core) Fix Version: (was: 3.2.1) On hold until after translator and grammar changes are complete > Ability to specify cascading in HQL delete > ------------------------------------------ > > Key: HHH-695 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-695 > Project: Hibernate3 > Type: New Feature > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > > > Add the ability to cascade HQL deletes. > Something like: > delete Person p cascade p.addresses > Obviously, this is better handled as in-DB cascade delete constraints, but for completeness... -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1267) HQL: order-by clause column list

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1267?page=all ] Steve Ebersole updated HHH-1267: -------------------------------- Fix Version: (was: 3.2.1) On hold until after translator and grammar changes are complete > HQL: order-by clause column list > -------------------------------- > > Key: HHH-1267 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1267 > Project: Hibernate3 > Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > > > HQL currently always results in using qualified column names in the order-by clause. Some databases (ok DB2) actually do not support this in all cases. And really according to the SQL spec, it is not the specified thing to do. Essentially the SQL spec says that if select-clause column aliases are used, those column aliases (or the column indexes) should be used in the order-by clause. > This should be the non-default behavior as it'll be more intensive of the query parser to achieve 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-294) implicit join in both subselect and outer query : single join

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-294?page=all ] Steve Ebersole updated HHH-294: ------------------------------- Fix Version: (was: 3.2.1) On hold until after translator and grammar changes are complete > implicit join in both subselect and outer query : single join > ------------------------------------------------------------- > > Key: HHH-294 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-294 > Project: Hibernate3 > Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > > > See HHH-280 for the details. > Basically, that was fixed by reverting to the old parser output of generating duplicate joins. This should be fixed to use the same join both times for effeciency. > There were a number of ways we might acheive this: > 1) Somehow suspend processing of subqueries until their containing query is completely processed. The trick here is that the join definition from the outer query would already have been resolved when processing the inner query resumes at which point we could simply reuse the join def from the outer query (this is the same thing as putting the implicit join in the outer query *before* the subquery, which works). This approach (while simple in its concept) seems very difficult to acheive with the ANTLR parser. > 2) Perform some post processing sort of like we do with the "join post processing". Yuck! > 3) When attempting to resolve the DotNode (representing the implicit join) take a peek at "child from clauses" to see if any of them defined the same "implicit join path"; if so "promote" that join fragment from the child FromClause to the current FromClause. > I will attempt #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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-16) Explicit joins on unrelated classes

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-16?page=all ] Steve Ebersole updated HHH-16: ------------------------------ Fix Version: 3.2.2 (was: 3.2.1) not going to be done for 3.2.1; more than likely this and the requisite translator changes actually will force a 3.3 line... > Explicit joins on unrelated classes > ----------------------------------- > > Key: HHH-16 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-16 > Project: Hibernate3 > Type: New Feature > Components: core > Environment: Any > Reporter: David Lloyd > Assignee: Steve Ebersole > Fix For: 3.2.2 > > > It would be nice to be able to do explicit joins on unrelated classes with HQL: > (hope this renders correctly) > select empl, phone > from org.example.Employee empl > left outer join org.example.PhoneBook phone > on phone.lastName = empl.lastName > and phone.firstName = empl.firstName > where empl.salaryGrade > 10 > Note that this would also implicity solve HB-1089 because you could list join criteria that match what Hibernate would have chosen anyway (i.e., list a many-to-one relationship as a criteria explicitly). > Syntactically this could be disambiguated from the existing join syntax because the token after "join" is a class name rather than a property name. -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1756) Proxy objects are not removed from the BatchFetchQueue during a session evict

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1756?page=all ] Steve Ebersole resolved HHH-1756: --------------------------------- Resolution: Fixed applied to trunk and 3.2 > Proxy objects are not removed from the BatchFetchQueue during a session evict > ----------------------------------------------------------------------------- > > Key: HHH-1756 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1756 > Project: Hibernate3 > Type: Bug > Components: core > Environment: Windows, Sybase, Hibernate Annotations > Reporter: Vadim Pertsovskiy > Assignee: Steve Ebersole > Fix For: 3.2.1 > > > When an entity loads, it initializes its children proxies and adds them to the BatchFetchQueue. The next time any of the proxies classes are loaded, hibernate retrieves additional objects rather then just the requested one. This works great, except if the user wants to evict the proxy from the BatchFetchQueue. Hibernate, incorrectly, does not do it. Once a proxy is added to the BatchFetchQueue, it's never removed unless the object is loaded. > To fix the problem, we've altered the SessionImpl class. During a proxy remove, the proxy is also removed from the BatchFetchQueue. > public Object removeProxy(EntityKey key) { > getBatchFetchQueue().removeBatchLoadableEntityKey(key); > getBatchFetchQueue().removeSubselect(key); > return proxiesByKey.remove(key); > } -- 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

17 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1775) collection batch fetching

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=all ] Steve Ebersole updated HHH-1775: -------------------------------- Fix Version: 3.2.2 (was: 3.2.1) not going to do this for 3.2.1 > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.2 > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- 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

17 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2006