Scott,
At last, I have found page cycling reason (... I think so ;-) ).

I have tried to build fresh turbine-torque from CVS HEAD.
I built it successfully using maven-1.0-beta-7 .
(by the way, I had to modify src/conf/master/Torque.master
in order to switch database adapter (It is hardcode there as "mysql")).

Running

maven runtime:test

against my as400 database profile
gives an error in LargeSelectTest:TestLargeSelect , in:

assertEquals("Total pages", 5, ls.getTotalPages());

I tried then to switch database. I installed postgresql.
All went ok, including LargeSelectTest:testForPaginationCycle
with my modifications. I tried also my client tiny application and it
works.

I noted (from log4j debug trace) that queries with postgresql included
a LIMIT clause that wasn't there in db2-as400 case.
I noted also that LargeSelect.results variable never exceeds memoryLimit.
If you remember my first email:
>This would be correct if results List wolud contain ONLY block
>results, but this is not true; results List contains all query
>results, including current block.

I suspect that LargeSelect is working as espected only with databases that
support OFFSET and LIMIT natively, like postgresql (may be Oracle?).

With db2400 (and mysql) LargeSelect does not performs well.
I think the problem is in mehod LargeSelect.getResults(int start, int size):
from my first email, again:
>In mehod getResults(int start, int size), fromIndex and toIndex
>variables indicates results List portion to return as a page.
>fromIndex is set to:
>fromIndex = start - blockBegin; when block size is equal to
>page size (memoryLimit == pageSize), fromIndex is always 0.
>The page is always the same.

Roberto.

P.S.:
There is a bug in Village 1.5.3 that prevents INSERT SQL statements to be
successful.
Inserts are enabled in Village in method

Schema.Schema schema(Connection conn, String tableName,  String columnsAttribute);
  Here a stmt is used to retrieve a ResultSetMetadata that is queried
to discover readOnly attribute of every table field.

In As400 is mandatory to create this stmt utilizing:

       conn.createStatement(
                ResultSet.TYPE_FORWARD_ONLY,
                ResultSet.CONCUR_UPDATABLE);

if you don't specify ResultSet.CONCUR_UPDATABLE
ResultSetMetadata will return ever readOnly=true, and it will be impossible
to update fields.
This behavior, by the way, is not catched as an error in Torque, but
results in generated SQL INSERT statements without field names and values,
as in:
INSERT ( ) INTO bookstore.Author VALUES ( )
>-- Messaggio Originale --
>Reply-To: "Turbine Torque Developers List"
>Date: Tue, 15 Oct 2002 23:18:51 +1000
>Subject: Re: LargeSelect bug?
>From: Scott Eade
>To: Turbine Torque Developers List
>
>
>Roberto,
>
>I have added the suggested lines to my test case and it still passes.
>
>Looking at your code fragments it is evident that you are not running the
>CVS HEAD code (which is probably not recommended at present anyway). I
am
>wondering if there is some other change that you do not have that is
>resulting in this problem occurring for you but not me.
>
>Is there a chance you could do a clean checkout to a new location and try
>again?
>
>Ciao,
>
>Scott
>--
>Scott Eade
>Backstage Technologies Pty. Ltd.
>http://www.backstagetech.com.au
>
>
>> From: [EMAIL PROTECTED]
>> Reply-To: "Turbine Torque Developers List"
>>
>> Date: Tue, 15 Oct 2002 14:40:59 +0200
>> To: "Turbine Torque Developers List"
>> Subject: Re: LargeSelect bug?
>>
>> Scott,
>> in your LargeSelectTest.testForPaginationCycle you don't
>> test record contents!
>>
>> Try to retrieve author_id from first record in first page and
>> compare it against author_id from first record in another page.
>>
>> In other words, add to LargeSelectTest.testForPaginationCycle
>> these two lines:
>>
>> // Page 1
>> int firstId = ((Author)(results.get(0))).getAuthorId().intValue();
>> // added line 1
>> ....
>>
>> // Page 5
>> assertTrue("first record contents",
>> // added line 2
>> ((Author)(results.get(0))).getAuthorId().intValue()
>> != firstId);
>> .....
>>
>> The last assert will fail, because result returned from every page are
>the
>> same,
>> (pagination cycling).
>> If memoryPageLimit > 1 cycling is present, but less evident.
>>
>> Roberto Resoli
>
>
>--
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>



__________________________________________________________________
Nuova Tiscali ADSL da 12,95 euro al mese.
Abbonati subito, entro il 31 ottobre l'attivazione e i consumi sono Gratis!

http://point.tiscali.it/ADSL/



--- Begin Message ---
Scott,
At last, I have found page cycling reason (... I think so ;-) ).

I have tried to build fresh turbine-torque from CVS HEAD.
I built it successfully using maven-1.0-beta-7 .
(by the way, I had to modify src/conf/master/Torque.master
in order to switch database adapter (It is hardcode there as "mysql")).

Running

maven runtime:test

against my as400 database profile
gives an error in LargeSelectTest:TestLargeSelect , in:

assertEquals("Total pages", 5, ls.getTotalPages());

I tried then to switch database. I installed postgresql.
All went ok, including LargeSelectTest:testForPaginationCycle
with my modifications. I tried also my client tiny application and it
works.

I noted (from log4j debug trace) that queries with postgresql included
a LIMIT clause that wasn't there in db2-as400 case.
I noted also that LargeSelect.results variable never exceeds memoryLimit.
If you remember my first email:
>This would be correct if results List wolud contain ONLY block
>results, but this is not true; results List contains all query
>results, including current block.

I suspect that LargeSelect is working as espected only with databases that
support OFFSET and LIMIT natively, like postgresql (may be Oracle?).

With db2400 (and mysql) LargeSelect does not performs well.
I think the problem is in mehod LargeSelect.getResults(int start, int size):
from my first email, again:
>In mehod getResults(int start, int size), fromIndex and toIndex
>variables indicates results List portion to return as a page.
>fromIndex is set to:
>fromIndex = start - blockBegin; when block size is equal to
>page size (memoryLimit == pageSize), fromIndex is always 0.
>The page is always the same.

Roberto.

P.S.:
There is a bug in Village 1.5.3 that prevents INSERT SQL statements to be
successful.
Inserts are enabled in Village in method

Schema.Schema schema(Connection conn, String tableName, String columnsAttribute);
        Here a stmt is used to retrieve a ResultSetMetadata that is queried
to discover readOnly attribute of every table field.

In As400 is mandatory to create this stmt utilizing:

             conn.createStatement(
                ResultSet.TYPE_FORWARD_ONLY,
                ResultSet.CONCUR_UPDATABLE);

if you don't specify  ResultSet.CONCUR_UPDATABLE
ResultSetMetadata will return ever readOnly=true, and it will be impossible
to update fields.
This behavior, by the way, is not catched as an error in Torque, but
results in generated SQL INSERT statements without field names and values,
as in:
INSERT ( ) INTO bookstore.Author VALUES ( )
>-- Messaggio Originale --
>Reply-To: "Turbine Torque Developers List" <[EMAIL PROTECTED]>
>Date: Tue, 15 Oct 2002 23:18:51 +1000
>Subject: Re: LargeSelect bug?
>From: Scott Eade <[EMAIL PROTECTED]>
>To: Turbine Torque Developers List <[EMAIL PROTECTED]>
>
>
>Roberto,
>
>I have added the suggested lines to my test case and it still passes.
>
>Looking at your code fragments it is evident that you are not running the
>CVS HEAD code (which is probably not recommended at present anyway).  I
am
>wondering if there is some other change that you do not have that is
>resulting in this problem occurring for you but not me.
>
>Is there a chance you could do a clean checkout to a new location and try
>again?
>
>Ciao,
>
>Scott
>--
>Scott Eade
>Backstage Technologies Pty. Ltd.
>http://www.backstagetech.com.au
>
>
>> From: [EMAIL PROTECTED]
>> Reply-To: "Turbine Torque Developers List"
>> <[EMAIL PROTECTED]>
>> Date: Tue, 15 Oct 2002 14:40:59 +0200
>> To: "Turbine Torque Developers List" <[EMAIL PROTECTED]>
>> Subject: Re: LargeSelect bug?
>>
>> Scott,
>> in your LargeSelectTest.testForPaginationCycle you don't
>> test record contents!
>>
>> Try to retrieve author_id from first record in first page and
>> compare it against author_id from first record in another page.
>>
>> In other words, add to LargeSelectTest.testForPaginationCycle
>> these two lines:
>>
>> // Page 1
>>       int firstId = ((Author)(results.get(0))).getAuthorId().intValue();
>> // added line 1
>> ....
>>
>> // Page 5
>>       assertTrue("first record contents",
>> // added line 2
>>                  ((Author)(results.get(0))).getAuthorId().intValue()
>>                  != firstId);
>> .....
>>
>> The last assert will fail, because result returned from every page are
>the
>> same,
>> (pagination cycling).
>> If memoryPageLimit > 1 cycling is present, but less evident.
>>
>> Roberto Resoli
>
>
>--
>To unsubscribe, e-mail:   <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org>
>For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org>
>


__________________________________________________________________
Nuova Tiscali ADSL da 12,95 euro al mese.
Abbonati subito, entro il 31 ottobre l'attivazione e i consumi sono Gratis!

http://point.tiscali.it/ADSL/





--- End Message ---
--
To unsubscribe, e-mail:   <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org>

Reply via email to