In that case I suspect you problem is not related to WebObjects or your code directly. ERXFetchSpecificationBatchIterator should be fast for 100's of thousands or rows. So it may be your database server configuration file at /etc/my.cnf, or even something else, is what is keeping this fetch from being faster.
care to share what the following SQL statement output is? SHOW CREATE TABLE artist; On Mar 21, 2012, at 10:32 AM, Ron X wrote: > ~50k > > 21 марта 2012 г. 14:41 пользователь Kieran Kelleher <[email protected]> > написал: > How many rows entirely? > > On Mar 21, 2012, at 6:39 AM, Ron X wrote: > >> >>Is it the first fetch for the primary keys that is failing? >> >> ERROR (ERXEOAccessUtilities.java:1213) - "Artist"@457777400 expression took >> 5289 ms: SELECT t0._rowid FROM artist t0 WHERE........ >> java.lang.RuntimeException: Statement running too long >> at >> er.extensions.eof.ERXEOAccessUtilities.logExpression(ERXEOAccessUtilities.java:1213) >> ..... >> yes, i think so. >> >> 21 марта 2012 г. 12:23 пользователь Johann Werner <[email protected]> написал: >> What means big? 1.000, 1.000.000, … ;) Is it the first fetch for the primary >> keys that is failing? >> A limit is used on a fetch spec if you set fetchSpec.setFetchLimit(int) but >> then it will probably not work with ERXFetchSpecificationBatchIterator. You >> should look at the logs and step through ERXFetchSpecificationBatchIterator >> with the debugger to get the part that is causing you trouble. >> >> >> Am 21.03.2012 um 09:48 schrieb Ron X: >> >>> Table is big, has indexes and in a good state. >>> How can i set to the framework to use LIMIT at all? >>> >>> 21 марта 2012 г. 10:47 пользователь Johann Werner <[email protected]> написал: >>> Hi Ron, >>> >>> looking at the code of ERXFetchSpecificationBatchIterator the first time >>> you call batchWithIndex all primary keys are fetched so that when you call >>> either batchWitchIndex, batchWithRange or nextBatch the select statement >>> that is sent to the DB will qualify the objects by pk IN (pk1, pk2, ...) >>> that's why you don't see a LIMIT statement. >>> How big is you Artist table? Which fetch is running too long, the one >>> fetching the pks or that getting the real objects? Is your DB in a good >>> state, do you have an index on your pk column? >>> >>> jw >>> >>> >>> Am 21.03.2012 um 08:29 schrieb Ron X: >>> >>> > hi everybody! >>> > i have real trouble with ERXFetchSpecificationBatchIterator >>> > >>> > EOQualifier qualifier = >>> > ERXQ.and(clazz.availabilityQuialifier, qualifierForLetter(letter)); >>> > EOFetchSpecification fs = new >>> > EOFetchSpecification(Artist.ENTITY_NAME, qualifier, Artist.NAME.ascs()); >>> > if (pagination != null) { >>> > ERXFetchSpecificationBatchIterator batchSpec = new >>> > ERXFetchSpecificationBatchIterator(fs); >>> > batchSpec.setBatchSize(10); >>> > NSArray<Artist> array = batchSpec.batchWithIndex(new >>> > Integer(pagination)); >>> > ... >>> > and than - i have statement running too long exception! >>> > i see that this batch DO NOT do LIMIT at the end of query! >>> > so i have 10 elements in array, but the request to DB (MySQL) is >>> > incredible! >>> > >>> > how can i fix this - to set the real LIMIT at the end of query? >>> >>> >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com >> >> This email sent to [email protected] > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
