We usually want ResultSet.TYPE_SCROLL_INSENSITIVE, which should work properly
on the database side.
We do NOT want ResultSet.TYPE_SCROLL_SENSITIVE because it is sensitive to
changes and has more performance impact.
Still, I'm guessing the information you are referring to is very old and I would be astounded if the Oracle JDBC driver
still had this issue, in fact I'm fairly sure it does not.
-David
phantom.coding wrote:
Agree that EntityListIterator keeps database cursor open and uses that to
retrive the results. Which means that we should use a scrollable cursor
(correct me if I'm wrong!!). But when working with ORACLE this doesn't work.
Oracle does not support scrollable cursors. It's the JDBC layer that
simulates the scrollable cursor and not the DB server. So even if we fetch
results 100 by 100 at JDBC level the full result set is fetched.
Pls correct me if i'm wrong
David E. Jones-2 wrote:
This is incorrect. The EntityListIterator uses a database cursor and
keeps the connection open to the database. Depending on what the
database and JDBC driver support and how things are configured, it
will typically pull over 100 records at a time over the network as it
scrolls through or jumps around the result set.
As to your specific performance problems, with that information I
have no idea what the problem might be. It depends on how you have
deployed OFBiz, how the database and JDBC driver are setup, and if
the custom or OOTB OFBiz code is written properly to use the
EntityListIterator.
-David
On Jan 31, 2007, at 4:53 PM, Jonathon -- Improov wrote:
I could be wrong, but it seems OFBiz pulls down all records (1000s
possibly) before putting all those records through that function.
Yeah, I know, the partial list is gleaned off of the resultset and
so it seems that we're not exactly swallowing all records first.
But isn't it more database-independent (or less?) to use SQL LIMIT?
I'm seeing long load times for LookUpProduct service when listing
for pagination a mere 1000 records. Perhaps it'll be much much
faster using SQL LIMIT? I know for a fact that using SQL LIMIT is
faster than scrolling through a resultset, know that based on my
own apps (currently having entity framework that provides for SQL
LIMIT).
Jonathon
David E. Jones wrote:
Could you explain how that would be different and better than
using the EntityListIterator.getPartialList method?
-David
On Jan 31, 2007, at 11:21 AM, Leon Torres wrote:
Hi David,
Sorry, maybe I should have expressed this in the form of two
questions.
Is there a way to do a query with OFFSET and LIMIT using
EntityCondition?
If not, then is there a way to do these offset and limit
operations with findEntityListIteratorByCondition?
- Leon
David E. Jones wrote:
What's wrong with the stuff that's been there for years on the
EntityListIterator?
-David
On Jan 30, 2007, at 4:52 PM, Leon Torres wrote:
Hi folks,
I think we really need to be able to specify the size of the
list we want and the index to start at for the
GenericDelegator.findByAnd and findByCondition methods.
The idea is to support pagination in the form widgets and
similar systems for lists of data that cannot be supported by
<view-entity>. For example, if the inventory QOH and ATP are
required for a form-widget list, we need to call the
getInventoryAvailableByFacility service and add the results to
each list row. Another example would be a union of various
entities together, some of which need heuristics to select the
data.
It should be relatively simple: Create a method that wraps a
call to findListIteratorByCondition, then grab the desired
range of results. It should also return the size of the table.
Then, as an example, we can call these methods with our
viewSize and viewIndex parameters, build our complex list of
data based on the results, and use the form-widget's override-
list-size to make pagination work with it.
Thoughts?
- Leon
