db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tiago R. Espinha (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3842) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorExternalSortJDBC30.sql" to junit.
Date Fri, 27 Mar 2009 13:28:51 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689893#action_12689893
] 

Tiago R. Espinha edited comment on DERBY-3842 at 3/27/09 6:28 AM:
------------------------------------------------------------------

I have started fixing the problems in my patch but you noticed one thing that had totally
skipped me: the comments mention that the cutover has been set to 4 rows, but even in the
old test it was already set to 5 rows.

This is wrong, right?

I'm just trying to make heads or tails of whether this has a direct implication on when we
do the commits on the fixtures.

I might just be about to say the wrongest thing ever but bear with me: having the sortBufferMax
set to 5, that means that when we're doing a sort operation that involves more than 5 records,
Derby will automatically use the hard drive to do the sort.

What are the implications of this from a test perspective? Do we need to commit() before or
after the 5th record is pulled?

This is just a little confusing considering that the comments say one thing and the actual
parameters tell a different story. It leaves me wondering whether the old test had already
been adapted for a sortBufferMax of 5 or if instead, it was still thought for a value of 4.

Some thoughts before I issue another patch please?

      was (Author: espinha):
    I have started fixing the problems in my patch but you noticed one thing that totally
skipped me: the comments mention that the cutover has been set to 4 rows, but even in the
old test it was already set to 5 rows.

This is wrong, right?

I'm just trying to make heads or tails of whether this has a direct implication on when we
do the commits on the fixtures.

I might just be about to say the wrongest thing ever but bear with me: having the sortBufferMax
set to 5, that means that when we're doing a sort operation that involves more than 5 records,
Derby will automatically use the hard drive to do the sort.

What are the implications of this from a test perspective? Do we need to commit() before or
after the 5th record is pulled?

This is just a little confusing considering that the comments say one thing and the actual
parameters tell a different story. It leaves me wondering whether the old test had already
been adapted for a sortBufferMax of 5 or if instead, it was still thought for a value of 4.

Some thoughts before I issue another patch please?
  
> Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorExternalSortJDBC30.sql"
to junit.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3842
>                 URL: https://issues.apache.org/jira/browse/DERBY-3842
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>            Reporter: Junjie Peng
>            Assignee: Tiago R. Espinha
>         Attachments: derby-3842-1.patch, derby-3842-1.stat, derby-3842-tiago.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message