[Hibernate-JIRA] Created: (HHH-3325) Pagination with Oracle ROWNUM is sub-optimal
by e. wernli (JIRA)
Pagination with Oracle ROWNUM is sub-optimal
--------------------------------------------
Key: HHH-3325
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3325
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Reporter: e. wernli
Pagination with Oracle ROWNUM is sub-optimal
The feature works but result in sub-optimal SQL. The generated SQL is the following:
select * from ( select row_.*, rownum rownum_ from ( select this_.id as id3_0_, this_.version as version3_0_, this_.name as name3_0_, this_.type as type3_0_, this_.marketstatus as marketst5_3_0_ from Customer this_ order by this_.id asc ) row_ ) where rownum_ <= ? and rownum_ > ?
But this SQL is faster:
SELECT *
FROM (SELECT row_.*, ROWNUM rownum_
FROM (SELECT this_.ID AS id3_0_, this_.VERSION AS version3_0_,
this_.NAME AS name3_0_, this_.TYPE AS type3_0_,
this_.marketstatus AS marketst5_3_0_
FROM customer this_
ORDER BY this_.ID ASC) row_
WHERE ROWNUM <= ?)
WHERE rownum_ > ?
The second solution allows Oracle to use an optimization that can dramatically reduce the time of the query, especially one of the first page is retrieved.
See this link for an explanation of this optimization: http://decipherinfosys.wordpress.com/2007/08/09/paging-and-countstopkey-o...
--
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
13 years, 3 months
[Hibernate-JIRA] Created: (HHH-2596) Add support for Hypersonic 1.8.0.7
by Gail Badner (JIRA)
Add support for Hypersonic 1.8.0.7
----------------------------------
Key: HHH-2596
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2596
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.3
Environment: Hibernate 3.2.3, Hypersonic 1.8.0.7
Reporter: Gail Badner
The version released with Hibernate 3.2.3 (1.8.0.2) is from 2005. It would be good to move to a more recent version.
The following unit tests fail when using Hypersonic 1.8.0.7:
org.hibernate.test.jpa.lock.JPALockTest.testLockModeTypeRead:
Failure: isolation not maintained expected:<lock test> but was:<updated>
org.hibernate.test.legacy.IJ2Test.testUnionSubclass:
Error: could not set a field value by reflection setter of org.hibernate.test.legacy.J.amount
org.hibernate.test.subclassfilter.UnionSubclassFilterTest.testFiltersWithUnionSubclass:
Error: Could not execute JDBC batch update
org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclass:
Failure: junit.framework.AssertionFailedError
org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclassManyToOne
Error: attempt to create delete event with null entity
--
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
13 years, 4 months
[Hibernate-JIRA] Created: (HHH-2578) redesign SessionFactory building
by Steve Ebersole (JIRA)
redesign SessionFactory building
--------------------------------
Key: HHH-2578
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2578
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Priority: Critical
Fix For: cfg-rework
Currently a SessionFactory is built by throwing a bunch of stuff into a Configuration object, stirring it, letting it come to a boil, and then pulling out the SessionFactory. In seriousness, there are a few problems with the way we currently operate within a Configuration and how we use it to build a SessionFactory:
The general issue that there is no "lifecycle" to when various pieces of information will be available. This is an important omission in a number of ways:
1) consider schema generation. currently we cannot even know the dialect when a lot of db object names are being determined. this would be nice because it would allow us to transparently handle table/column names which are also keywords/reserved-words in the dialect, for example.
2) static-ness of types and the type-mappings. Because we currently have nothing to which to scope them. Ideally a type instance would be aware of the SessionFactory to which it is bound. Instead, what we have now is to change API methods quite a lot of the time to add in the SessionFactory as a passed parameter whenever it is discovered that it is needed.
3) also, most (all?) of the "static" configuration parameters in Hibernate are currently required to be so because of their use from within these static types; thus scoping types would allow us to also scope those config parameters (things like bytecode-provider, use of binary streams, etc).
Ideally what I see happening is a scheme where users build a org.hibernate.cfg.Settings (or something similiar) instance themselves. Additionally they would apply metadata to a registry of some sort (lets call it MetadataRegistry for now). Then in order to build a SessionFactory, they would supply these two pieces of information (via ctor? via builder?). The important aspect though is that the information in MetadataRegistry would not be dealt with until that point in time, which would allow us to guarentee that resolving schema object names, types, etc would have access to the runtime Settings (and specifically the dialect)
--
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
13 years, 4 months