Обсуждение: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PG Data-types in Query Tool

Hi,

As we have been facing many issues with different data-type display in Query Tool output, Dave suggested to write the feature test for the same.

I have started with some basic set of data-type values and will add more.

Please find the attached initial patch for the same.

BTW - on a related note, I was seeing this failure in the tests:

FAIL: runTest (pgadmin.feature_tests.pg_datatype_validation_test.PGDataypeFeatureTest)

Test checks for PG data-types output

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py", line 42, in runTest

    self._check_datatype()

  File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py", line 111, in _check_datatype

    assert False, "{0} does not match with {1}".format(val, expected_output[cnt])

AssertionError: ARRAY[1, 2, 'nan']::float[] does not match with 1, 2, 'nan'

On Thu, May 11, 2017 at 10:11 AM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

As we have been facing many issues with different data-type display in Query Tool output, Dave suggested to write the feature test for the same.

I have started with some basic set of data-type values and will add more.

Please find the attached initial patch for the same.

Some thoughts:

- Instead of sleeping, which is almost always a bad design, can we wait for objects to appear?

- Currently you're testing each datatype with an individual query, e.g.

SELECT 32768;

I would suggest we test all datatypes at once, e.g.

SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;

etc. That will massively reduce the time taken to execute the tests (which is a big concern).

- Shouldn't we be casting the values in the SELECT, so we (and the database) know exactly what we're expecting? e.g.

SELECT 32768::int, 43723489023489::bigint, '2017-09-12 15:34:11':timestamp, 12345.56::numeric(8,4);

That would also allow us to verify the type name displayed in the column headers.

Thanks!

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, May 11, 2017 at 2:45 PM, Dave Page <dpage@pgadmin.org> wrote:

BTW - on a related note, I was seeing this failure in the tests:

FAIL: runTest (pgadmin.feature_tests.pg_datatype_validation_test.PGDataypeFeatureTest)

Test checks for PG data-types output

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py", line 42, in runTest

    self._check_datatype()

  File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py", line 111, in _check_datatype

    assert False, "{0} does not match with {1}".format(val, expected_output[cnt])

AssertionError: ARRAY[1, 2, 'nan']::float[] does not match with 1, 2, 'nan'

Yes this issue is already logged in redmine. When we execute SELECT ARRAY[1, 2, 'nan']::float[]; from Query tool, we don't get output. The "Data Output" panel remains blank and in message panel we get  {"info":"","success":1,"errormsg":"","data":{"rows_affected":1,"result":[[[1.0,2.0,NaN]]],"additional_messages":null,"status":"Success"},"result":null}.

Due to this error, I have executed different query for each value. If I run a single query, the test case fails and I can't get the desired output.

I have also tried to clear the SQL editor for each query and avoid loading Query tool for their respective call but I couldn't.

I will work on your other suggestion.

On Thu, May 11, 2017 at 10:11 AM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

As we have been facing many issues with different data-type display in Query Tool output, Dave suggested to write the feature test for the same.

I have started with some basic set of data-type values and will add more.

Please find the attached initial patch for the same.

Some thoughts:

- Instead of sleeping, which is almost always a bad design, can we wait for objects to appear?

- Currently you're testing each datatype with an individual query, e.g.

SELECT 32768;

I would suggest we test all datatypes at once, e.g.

SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;

etc. That will massively reduce the time taken to execute the tests (which is a big concern).

- Shouldn't we be casting the values in the SELECT, so we (and the database) know exactly what we're expecting? e.g.

SELECT 32768::int, 43723489023489::bigint, '2017-09-12 15:34:11':timestamp, 12345.56::numeric(8,4);

That would also allow us to verify the type name displayed in the column headers.

Thanks!

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi

On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

As we have been facing many issues with different data-type display in Query Tool output, Dave suggested to write the feature test for the same.

I have started with some basic set of data-type values and will add more.

Please find the attached initial patch for the same.

Some thoughts:

- Instead of sleeping, which is almost always a bad design, can we wait for objects to appear?

- Currently you're testing each datatype with an individual query, e.g.

SELECT 32768;

I would suggest we test all datatypes at once, e.g.

SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;

etc. That will massively reduce the time taken to execute the tests (which is a big concern).

- Shouldn't we be casting the values in the SELECT, so we (and the database) know exactly what we're expecting? e.g.

SELECT 32768::int, 43723489023489::bigint, '2017-09-12 15:34:11':timestamp, 12345.56::numeric(8,4);

That would also allow us to verify the type name displayed in the column headers.

Thanks!

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi

What are the sleeps in pgadmin_page.py for? Can we get rid of them?

On Thu, May 25, 2017 at 6:06 AM, Khushboo Vashi

<khushboo.vashi@enterprisedb.com> wrote:
> Hi,
>
> Please find the attached updated patch.
>
> Thanks,
> Khushboo
>
> On Thu, May 11, 2017 at 2:41 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi
>> <khushboo.vashi@enterprisedb.com> wrote:
>>>
>>> Hi,
>>>
>>> As we have been facing many issues with different data-type display in
>>> Query Tool output, Dave suggested to write the feature test for the same.
>>>
>>> I have started with some basic set of data-type values and will add more.
>>> Please find the attached initial patch for the same.
>>
>>
>> Some thoughts:
>>
>> - Instead of sleeping, which is almost always a bad design, can we wait
>> for objects to appear?
>>
> Fixed
>>
>> - Currently you're testing each datatype with an individual query, e.g.
>>
>> SELECT 32768;
>>
>> I would suggest we test all datatypes at once, e.g.
>>
>> SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;
>>
>> etc. That will massively reduce the time taken to execute the tests (which
>> is a big concern).
>>
> Fixed
>>
>> - Shouldn't we be casting the values in the SELECT, so we (and the
>> database) know exactly what we're expecting? e.g.
>>
> Fixed
>>
>> SELECT 32768::int, 43723489023489::bigint, '2017-09-12
>> 15:34:11':timestamp, 12345.56::numeric(8,4);
>>
>> That would also allow us to verify the type name displayed in the column
>> headers.
>>
>> Thanks!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company