Re: pgagent unicode support

2021-02-25 Thread Neel Patel
Hi Dave/Ashesh,

Do you have any further comments ?

Thanks,
Neel Patel

On Wed, Feb 24, 2021 at 8:14 PM Sergey Burladyan 
wrote:

> Neel Patel  writes:
>
> > Thanks for the review. Please find the attached updated patch.
> > Do review it and let me know in case of any comments.
>
> Looks good, thanks!
>
> --
> Sergey Burladyan
>


Re: pgagent unicode support

2021-02-24 Thread Neel Patel
Hi Sergey,

Thanks for the review. Please find the attached updated patch.
Do review it and let me know in case of any comments.

Thanks,
Neel Patel

On Wed, Feb 24, 2021 at 5:12 PM Sergey Burladyan 
wrote:

> Sergey Burladyan  writes:
>
> > Maybe it should look something like this:
> > +wcstombs_s(, mbs, mb_len + 1, wchar_str, mb_len);
>
> Ah, and we missed check for error.
>
> Something like this, maybe:
> +#ifdef __WIN32__
> +size_t charsConverted = 0;
> +if (wcstombs_s(, mbs, mb_len + 1, wchar_str,
> mb_len) != 0) {
> +delete [] mbs;
> +return NULL;
> +}
> +#else
>
> --
> Sergey Burladyan
>


pgagent_unicode_v2.patch
Description: Binary data


Re: pgagent unicode support

2021-02-23 Thread Neel Patel
Hi Sergey,

Do you have any comments for this updated patch ? Let us know ASAP so that
we can commit it.

Thanks,
Neel Patel

On Thu, Feb 18, 2021 at 5:12 PM Neel Patel 
wrote:

> Hi Sergey,
>
> Thank you for the patch. It looks good to me except below.
>
> We have modified the patch as we fixed the memory leak ( review comment
> given by Ashesh ) and also fixed the compilation warnings.
> Can you please review and let us know ?
>
> Thanks,
> Neel Patel
>
> On Mon, Feb 15, 2021 at 6:15 PM Neel Patel 
> wrote:
>
>> Thanks Sergey for the patch.
>>
>> Sure Dave.
>> There is some compilation warning in linux, I will fix those and test
>> pgAgent in windows and update the thread.
>>
>> On Mon, Feb 8, 2021 at 2:55 PM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan 
>>> wrote:
>>>
>>>> Currently pgagent doesn't handle unicode correctly.
>>>>
>>>> CharToWString function corrupt multibyte characters because it processes
>>>> string one byte at a time:
>>>>  148 std::string s = std::string(cstr);
>>>>  149 std::wstring wsTmp(s.begin(), s.end());
>>>>
>>>> WStringToChar function does not take into account that there can be
>>>> _multi_byte character on wcstombs output and create buffer with
>>>> size = wcslen:
>>>>  157 int wstr_length = wcslen(wchar_str);
>>>>  158 char *dst = new char[wstr_length + 10];
>>>>
>>>> Also pgagent do not setup locale with setlocale(), without it all
>>>> wcs/mbs functions cannot handle multibyte strings.
>>>>
>>>> For example:
>>>>
>>>> === step code ===
>>>> select 'это проверка кириллицы в теле запроса pgagent'
>>>> =
>>>>
>>>> === postgres log ===
>>>> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR:
>>>> unterminated quoted string at or near "'" at character 8
>>>> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT:  select
>>>> '
>>>> 
>>>>
>>>> Please see attached patch.
>>>> I only test it on GNU/Linux and can't test it on Windows, sorry.
>>>>
>>>
>>> Thanks for the patch! Neel/Ashesh; can you take a look please? It looks
>>> OK to me, but then I'm not overly familiar with multibyte string handling.
>>> What, if anything, needs to be done on Windows?
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EDB: http://www.enterprisedb.com
>>>
>>>


Re: pgagent unicode support

2021-02-18 Thread Neel Patel
Hi Sergey,

Thank you for the patch. It looks good to me except below.

We have modified the patch as we fixed the memory leak ( review comment
given by Ashesh ) and also fixed the compilation warnings.
Can you please review and let us know ?

Thanks,
Neel Patel

On Mon, Feb 15, 2021 at 6:15 PM Neel Patel 
wrote:

> Thanks Sergey for the patch.
>
> Sure Dave.
> There is some compilation warning in linux, I will fix those and test
> pgAgent in windows and update the thread.
>
> On Mon, Feb 8, 2021 at 2:55 PM Dave Page  wrote:
>
>> Hi
>>
>> On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan 
>> wrote:
>>
>>> Currently pgagent doesn't handle unicode correctly.
>>>
>>> CharToWString function corrupt multibyte characters because it processes
>>> string one byte at a time:
>>>  148 std::string s = std::string(cstr);
>>>  149 std::wstring wsTmp(s.begin(), s.end());
>>>
>>> WStringToChar function does not take into account that there can be
>>> _multi_byte character on wcstombs output and create buffer with
>>> size = wcslen:
>>>  157 int wstr_length = wcslen(wchar_str);
>>>  158 char *dst = new char[wstr_length + 10];
>>>
>>> Also pgagent do not setup locale with setlocale(), without it all
>>> wcs/mbs functions cannot handle multibyte strings.
>>>
>>> For example:
>>>
>>> === step code ===
>>> select 'это проверка кириллицы в теле запроса pgagent'
>>> =
>>>
>>> === postgres log ===
>>> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR:
>>> unterminated quoted string at or near "'" at character 8
>>> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT:  select '
>>> 
>>>
>>> Please see attached patch.
>>> I only test it on GNU/Linux and can't test it on Windows, sorry.
>>>
>>
>> Thanks for the patch! Neel/Ashesh; can you take a look please? It looks
>> OK to me, but then I'm not overly familiar with multibyte string handling.
>> What, if anything, needs to be done on Windows?
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EDB: http://www.enterprisedb.com
>>
>>


pgagent_unicode.patch
Description: Binary data


Re: pgagent unicode support

2021-02-15 Thread Neel Patel
Thanks Sergey for the patch.

Sure Dave.
There is some compilation warning in linux, I will fix those and test
pgAgent in windows and update the thread.

On Mon, Feb 8, 2021 at 2:55 PM Dave Page  wrote:

> Hi
>
> On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan 
> wrote:
>
>> Currently pgagent doesn't handle unicode correctly.
>>
>> CharToWString function corrupt multibyte characters because it processes
>> string one byte at a time:
>>  148 std::string s = std::string(cstr);
>>  149 std::wstring wsTmp(s.begin(), s.end());
>>
>> WStringToChar function does not take into account that there can be
>> _multi_byte character on wcstombs output and create buffer with
>> size = wcslen:
>>  157 int wstr_length = wcslen(wchar_str);
>>  158 char *dst = new char[wstr_length + 10];
>>
>> Also pgagent do not setup locale with setlocale(), without it all
>> wcs/mbs functions cannot handle multibyte strings.
>>
>> For example:
>>
>> === step code ===
>> select 'это проверка кириллицы в теле запроса pgagent'
>> =
>>
>> === postgres log ===
>> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR:  unterminated
>> quoted string at or near "'" at character 8
>> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT:  select '
>> 
>>
>> Please see attached patch.
>> I only test it on GNU/Linux and can't test it on Windows, sorry.
>>
>
> Thanks for the patch! Neel/Ashesh; can you take a look please? It looks OK
> to me, but then I'm not overly familiar with multibyte string handling.
> What, if anything, needs to be done on Windows?
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: http://www.enterprisedb.com
>
>


Re: pgAgent build warnings on Fedora 32

2020-09-09 Thread Neel Patel
Hi Devrim,

I have tried with gcc 10.1 on Ubuntu and I checked the logs but did not
find any warning. Below is my setup and logs during pgAgent compilation.
Is there any specific gcc 10.X version ? Let me know, I can set up and send
a patch.

#

neel@ubuntu:~/Projects/pgagent/build$ c++ --version
c++ (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


neel@ubuntu:~/Projects/pgagent/build$ g++ --version
g++ (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


neel@ubuntu:~/Projects/pgagent/build$ gcc --version
gcc (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


neel@ubuntu:~/Projects/pgagent/build$
PATH=/opt/PostgreSQL/10/bin:$PATH cmake ../ -DSTATIC_BUILD=NO
-DCMAKE_PREFIX_PATH=/home/neel/pgagent_install
-- The C compiler identification is GNU 10.1.0
-- The CXX compiler identification is GNU 10.1.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   filesystem
--   regex
--   date_time
--   thread
--   system
--   chrono
--   atomic
--
-- 

-- Configuration summary:
--
--   Project : pgagent
--   Description : pgAgent is a job scheduling engine
for PostgreSQL
--   Version : 4.2.0
--
--   PostgreSQL version string   : PostgreSQL 10.11
--   PostgreSQL version parts: 10
--   PostgreSQL path : /opt/PostgreSQL/10
--   PostgreSQL config binary: /opt/PostgreSQL/10/bin/pg_config
--   PostgreSQL include path : /opt/PostgreSQL/10/include
--   PostgreSQL library path : /opt/PostgreSQL/10/lib
--   PostgreSQL share path   : /opt/PostgreSQL/10/share/postgresql
--
--   Boost version   : 1.65.1
--   Boost path  : /usr/include
--   Boost include directory : /usr/include
--   Boost library directory : /usr/lib/x86_64-linux-gnu
--   Boost Static linking: NO
-- 

--
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/neel/Projects/pgagent/buildneel@ubuntu:~/Projects/pgagent/build$
make
Scanning dependencies of target run
[ 11%] Generating pgagent--4.2.sql, pgagent.control
[ 11%] Built target run
Scanning dependencies of target pgagent
[ 22%] Building CXX object CMakeFiles/pgagent.dir/connection.cpp.o
[ 33%] Building CXX object CMakeFiles/pgagent.dir/job.cpp.o
[ 44%] Building CXX object CMakeFiles/pgagent.dir/misc.cpp.o
[ 55%] Building CXX object CMakeFiles/pgagent.dir/pgAgent.cpp.o
[ 66%] Building CXX object CMakeFiles/pgagent.dir/precomp.cpp.o
[ 77%] Building CXX object CMakeFiles/pgagent.dir/unix.cpp.o
[ 88%] Building CXX object CMakeFiles/pgagent.dir/win32.cpp.o
[100%] Linking CXX executable pgagent
[100%] Built target pgagent

###


On Wed, Sep 9, 2020 at 7:39 PM Devrim Gündüz  wrote:

>
> Hi Neel,
>
> On Fri, 2020-04-24 at 18:15 +0530, Neel Patel wrote:
> > I will look into it.
>
> Any updates?
>
> Cheers,
> --
> Devrim Gündüz
> Open Source Solution Architect, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>


Re: Raise an exception under Python < 3.4

2020-04-29 Thread Neel Patel
Hi,

On Wed, Apr 29, 2020 at 2:52 PM Dave Page  wrote:

> Hi
>
> On Wed, Apr 29, 2020 at 10:13 AM Neel Patel 
> wrote:
>
>> Hi Dave,
>>
>> Patch looks good to me except one condition as we do support from Python
>> 3.4 onwards. I have modified that condition and attached the updated patch.
>>
>
> What did you change exactly (curious about what I missed)?
>

Previously it was like,

*+if sys.version_info < (3, 3):*
*+raise Exception('This application must be run under Python 3.4 or
later.')*

Modified as below.

*+if sys.version_info < (3, 4):*

*+raise Exception('This application must be run under Python 3.4 or
later.')*




>
>>
>> I have also removed the other references of Python2. Attached is the
>> patch. Do review it and let me know for comments.
>>
>
> I think there's a lot more than that - try searching the entire tree for
> PY2 or sys.version. This was on my personal todo as a next step, but feel
> free to update your patch :-)
>

Sure.


>
> Thanks!
>
>
>>
>> Thanks,
>> Neel Patel
>>
>> On Mon, Apr 27, 2020 at 9:27 PM Dave Page  wrote:
>>
>>> The attached patch raises an exception if run under Python < 3.4. It
>>> also cleans up the README to remove references to Python 2 and removes
>>> Python 2-isms from the main config.
>>>
>>> --
>>> 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
>


Re: Raise an exception under Python < 3.4

2020-04-29 Thread Neel Patel
Hi Dave,

Patch looks good to me except one condition as we do support from Python
3.4 onwards. I have modified that condition and attached the updated patch.

I have also removed the other references of Python2. Attached is the patch.
Do review it and let me know for comments.

Thanks,
Neel Patel

On Mon, Apr 27, 2020 at 9:27 PM Dave Page  wrote:

> The attached patch raises an exception if run under Python < 3.4. It also
> cleans up the README to remove references to Python 2 and removes Python
> 2-isms from the main config.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Throw_an_exception_if_run_under_Python__=_3_3,_and_update_the_docs_and_main_config_for_Pyt_v2.patch
Description: Binary data


Remove_Python2_Reference_Core_files.patch
Description: Binary data


Re: Remove Python 2 support from the desktop runtime

2020-04-28 Thread Neel Patel
Hi Dave,

I reviewed and tested and it looks good to me.

Thanks,
Neel Patel

On Tue, Apr 28, 2020 at 1:32 PM Dave Page  wrote:

> Apparently, yes :-(
>
> On Mon, Apr 27, 2020 at 9:15 PM Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Did you forget to attach?
>>
>> — Ashesh
>>
>> On Mon, 27 Apr 2020 at 21:47, Dave Page  wrote:
>>
>>> Patch for $SUBJECT attached.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>> --
>>
>> --
>>
>> Thanks & Regards,
>>
>> Ashesh Vashi
>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>> <http://www.enterprisedb.com>
>>
>>
>> *http://www.linkedin.com/in/asheshvashi*
>> <http://www.linkedin.com/in/asheshvashi>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: pgAgent build warnings on Fedora 32

2020-04-24 Thread Neel Patel
I will look into it.

On Fri, Apr 24, 2020 at 5:51 PM Devrim Gündüz  wrote:

>
> Hi,
>
> pgAgent throws the warnings below while compiling it on Fedora 32, which
> uses GCC 10. Can you please take a look?
>
> Thanks! Devrim
>
> ===
>  /usr/bin/make
> DESTDIR=/var/lib/pgsql/rpm12/BUILDROOT/pgagent_12-4.0.0-4.f32.x86_64 install
> In file included from
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/pgAgent.h:36,
>  from
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:12:
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h: In
> constructor 'DBconn::DBconn(const wstring&)':
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:117:19:
> warning: 'DBconn::m_inUse' will be initialized after [-Wreorder]
>   117 |  bool m_inUse;
>   |   ^~~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:113:19:
> warning:   'DBconn* DBconn::m_next' [-Wreorder]
>   113 |  DBconn  *m_next;
>   |   ^~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:21:1:
> warning:   when initialized here [-Wreorder]
>21 | DBconn::DBconn(const std::wstring )
>   | ^~
> In file included from
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/pgAgent.h:36,
>  from
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:12:
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:114:19:
> warning: 'DBconn::m_prev' will be initialized after [-Wreorder]
>   114 |  DBconn  *m_prev;
>   |   ^~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:102:19:
> warning:   'int DBconn::m_minorVersion' [-Wreorder]
>   102 |  int  m_minorVersion,
>   |   ^~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:21:1:
> warning:   when initialized here [-Wreorder]
>21 | DBconn::DBconn(const std::wstring )
>   | ^~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp: In member
> function 'std::wstring DBconn::ExecuteScalar(const wstring&)':
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:333:6:
> warning: variable 'rows' set but not used [-Wunused-but-set-variable]
>   333 |  int rows = -1;
>   |  ^~~~
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/job.cpp: In member
> function 'int Job::Execute()':
> /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/job.cpp:157:9: warning:
> unused variable 'last_n_char' [-Wunused-variable]
>   157 | int last_n_char = 7;
>   | ^~~
>
> --
> Devrim Gündüz
> Open Source Solution Architect, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>


Re: [pgagent]: Modified 'next_schedule' function and updated pgagent 4.2 version

2020-04-24 Thread Neel Patel
Hi Dave,

On Fri, Apr 24, 2020 at 3:00 PM Dave Page  wrote:

>
>
> On Fri, Apr 24, 2020 at 10:23 AM Vik Fearing 
> wrote:
>
>>
>>
>> On Fri, Apr 24, 2020 at 11:10 AM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Thu, Apr 23, 2020 at 12:21 PM Neel Patel 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find an updated patch that fixes a bug in 'next_schedule'
>>>> function where minute should be extracted instead of year for calculation.
>>>>
>>>> Issue found by: Vik Fearing
>>>>
>>>> Please find the attached patch that fixed the issue in respective
>>>> pgagent files and updated pgagent for 4.2 version.
>>>>
>>>> Do review it and let me know for comments.
>>>>
>>>
>>> Any reason not to use the rewritten version of the function that Vik
>>> wrote? It updated it to use much more modern features of pl/pgsql, rather
>>> than the now 15 year old syntax that's currently used.
>>>
>>>
>>
>> Well, the current version has received 15 years of testing (despite the
>> bug I found), and my rewrite has only received some local testing by me.  I
>> would like to see my version eventually integrated, but I don't think it
>> should be rushed in.
>>
>
> Good point - patch applied, thanks.
>
> Neel, can you work with the team to do some testing of the function
> rewrite as a spare-time project please?
>

Sure.


>
> Thanks!
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


[pgagent]: Modified 'next_schedule' function and updated pgagent 4.2 version

2020-04-23 Thread Neel Patel
Hi,

Please find an updated patch that fixes a bug in 'next_schedule' function
where minute should be extracted instead of year for calculation.

Issue found by: Vik Fearing

Please find the attached patch that fixed the issue in respective pgagent
files and updated pgagent for 4.2 version.

Do review it and let me know for comments.

Thanks,
Neel Patel


pgagent_4_2.patch
Description: Binary data


Re: [Patch][pgAdmin4]: Fix pgagent issues

2020-04-21 Thread Neel Patel
Hi Akshay,

Please find the attached update patch with the fix.
Also fixed the Roles resql test cases as it was failing due to timezone
change.

Thanks,
Neel Patel

On Tue, Apr 21, 2020 at 12:32 PM Akshay Joshi 
wrote:

> Hi Neel
>
> RESQL test cases are failing on my machine due to different timezone
>
> - '2020-04-14 01:11:31-07'::timestamp with time zone, '2020-04-15
> 01:11:34-07'::timestamp with time zone,
> ? -  ^^ ^ -  ^
>^ ^
> + '2020-04-14 13:41:31+05:30'::timestamp with time zone, '2020-04-15
> 13:41:34+05:30'::timestamp with time zone,
> ?  + ^^ 
>  + ^^ 
>
> Please fix the above issue and resend the patch.
>
> On Mon, Apr 20, 2020 at 3:07 PM Neel Patel 
> wrote:
>
>> Hi,
>>
>> Please find the attached patch to stabilize the pgagent and fix below
>> issues.
>>
>>- Reverse engineering SQL and MSQL was incorrect when the user added
>>a job schedule with exception Fixes #5356
>>- Job schedule exception time was not showing correctly in SQL tab.
>>- Identify the job step and schedule if disabled from browser tree,
>>same as pgagent job - Fixes #4636
>>- Add RE-SQL/MSQL test cases for pgAgent Jobs - Fixes #4623
>>
>> Do review it and let me know for comments.
>>
>> Thanks,
>> Neel Patel
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>
diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
index 797a6cb..ee87a1a 100644
--- a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
+++ b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
@@ -10,6 +10,7 @@
 """Implements the pgAgent Jobs Node"""
 from functools import wraps
 import json
+from datetime import datetime, time
 
 from flask import render_template, request, jsonify
 from flask_babelex import gettext as _
@@ -323,7 +324,8 @@ SELECT EXISTS(
 row['jobid'],
 sid,
 row['jobname'],
-icon="icon-pga_job"
+icon="icon-pga_job" if row['jobenabled']
+else "icon-pga_job-disabled"
 )
 )
 
@@ -500,6 +502,10 @@ SELECT EXISTS(
 if schedule['jexid']:
 idx = 0
 for exc in schedule['jexid']:
+# Convert datetime.time object to string
+if isinstance(schedule['jextime'][idx], time):
+schedule['jextime'][idx] = \
+schedule['jextime'][idx].strftime("%H:%M:%S")
 schedule['jscexceptions'].append({
 'jexid': exc,
 'jexdate': schedule['jexdate'][idx],
diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py
index ad3e7e9..13bd25a 100644
--- a/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py
+++ b/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py
@@ -74,6 +74,23 @@ class JobScheduleModule(CollectionNodeModule):
 return 'pga_job'
 
 @property
+def csssnippets(self):
+"""
+Returns a snippet of css to include in the page
+"""
+snippets = [
+render_template(
+"pga_schedule/css/pga_schedule.css",
+node_type=self.node_type
+)
+]
+
+for submodule in self.submodules:
+snippets.extend(submodule.csssnippets)
+
+return snippets
+
+@property
 def module_use_template_javascript(self):
 """
 Returns whether Jinja2 template is used for generating the javascript
@@ -245,7 +262,8 @@ class JobScheduleView(PGChildNodeView):
 row['jscid'],
 row['jscjobid'],
 row['jscname'],
-icon="icon-pga_schedule",
+icon="icon-pga_schedule" if row['jscenabled'] else
+"icon-pga_schedule-disabled",
 enabled=row['jscenabled']
 )
 )
@@ -256,7 +274,8 @@ class JobScheduleView(PGChildNodeView):
 row['jscid'],
 row['jscjobid'],
 row['jscname'],
-icon="icon-pga_schedule",
+icon="icon-pga_schedule" if row['jscenabled'] else
+   

[Patch][pgAdmin4]: Fix pgagent issues

2020-04-20 Thread Neel Patel
Hi,

Please find the attached patch to stabilize the pgagent and fix below
issues.

   - Reverse engineering SQL and MSQL was incorrect when the user added a
   job schedule with exception Fixes #5356
   - Job schedule exception time was not showing correctly in SQL tab.
   - Identify the job step and schedule if disabled from browser tree, same
   as pgagent job - Fixes #4636
   - Add RE-SQL/MSQL test cases for pgAgent Jobs - Fixes #4623

Do review it and let me know for comments.

Thanks,
Neel Patel
diff --git a/docs/en_US/release_notes_4_21.rst b/docs/en_US/release_notes_4_21.rst
index d2a42eb..9f152ee 100644
--- a/docs/en_US/release_notes_4_21.rst
+++ b/docs/en_US/release_notes_4_21.rst
@@ -11,6 +11,7 @@ New features
 
 | `Issue #2172 <https://redmine.postgresql.org/issues/2172>`_ -  Added search object functionality.
 | `Issue #2186 <https://redmine.postgresql.org/issues/2186>`_ -  Added LDAP authentication support.
+| `Issue #4636 <https://redmine.postgresql.org/issues/4636>`_ -  Added job step and job schedule disable icons to identify it quickly within browser tree.
 | `Issue #5181 <https://redmine.postgresql.org/issues/5181>`_ -  Added support for parameter toast_tuple_target and parallel_workers of the table.
 | `Issue #5263 <https://redmine.postgresql.org/issues/5263>`_ -  Added support of Foreign Tables to the Schema Diff.
 | `Issue #5264 <https://redmine.postgresql.org/issues/5264>`_ -  Added support of Packages, Sequences and Synonyms to the Schema Diff.
@@ -21,6 +22,7 @@ Housekeeping
 
 
 | `Issue #4620 <https://redmine.postgresql.org/issues/4620>`_ -  Add Reverse Engineered and Modified SQL tests for procedures.
+| `Issue #4623 <https://redmine.postgresql.org/issues/4623>`_ -  Add Reverse Engineered and Modified SQL tests for pgagent jobs.
 
 Bug fixes
 *
@@ -57,6 +59,7 @@ Bug fixes
 | `Issue #5302 <https://redmine.postgresql.org/issues/5302>`_ -  Fixed an issue where difference SQL is not seen in the schema diff tool for Types.
 | `Issue #5314 <https://redmine.postgresql.org/issues/5314>`_ -  Ensure that switch cell is in sync with switch control for accessibility.
 | `Issue #5351 <https://redmine.postgresql.org/issues/5351>`_ -  Fixed compilation warnings while building pgAdmin.
+| `Issue #5356 <https://redmine.postgresql.org/issues/5356>`_ -  Fixed msql creation issue while adding exception in pgaagent job schedule.
 | `Issue #5361 <https://redmine.postgresql.org/issues/5361>`_ -  Fixes an issue where pgAdmin4 GUI does not display properly in IE 11.
 | `Issue #5362 <https://redmine.postgresql.org/issues/5362>`_ -  Fixed an issue where the identical packages and sequences visible as different in the schema diff tool.
 | `Issue #5366 <https://redmine.postgresql.org/issues/5366>`_ -  Added alert message to Reset Layout if any of the panels from Query Tool failed to load.
@@ -66,4 +69,4 @@ Bug fixes
 | `Issue #5387 <https://redmine.postgresql.org/issues/5387>`_ -  Fixed an issue where the mode is not shown in the properties dialog of functions/procedures if all the arguments are "IN" arguments.
 | `Issue #5400 <https://redmine.postgresql.org/issues/5400>`_ -  Fixed internal server error when the database server is logged in with non-super user.
 | `Issue #5409 <https://redmine.postgresql.org/issues/5409>`_ -  Fixed validation issue in Synonyms node.
-| `Issue #5410 <https://redmine.postgresql.org/issues/5410>`_ -  Fixed an issue while removing the package body showing wrong modified SQL.
\ No newline at end of file
+| `Issue #5410 <https://redmine.postgresql.org/issues/5410>`_ -  Fixed an issue while removing the package body showing wrong modified SQL.
diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
index 797a6cb..ee87a1a 100644
--- a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
+++ b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py
@@ -10,6 +10,7 @@
 """Implements the pgAgent Jobs Node"""
 from functools import wraps
 import json
+from datetime import datetime, time
 
 from flask import render_template, request, jsonify
 from flask_babelex import gettext as _
@@ -323,7 +324,8 @@ SELECT EXISTS(
 row['jobid'],
 sid,
 row['jobname'],
-icon="icon-pga_job"
+icon="icon-pga_job" if row['jobenabled']
+else "icon-pga_job-disabled"
 )
 )
 
@@ -500,6 +502,10 @@ SELECT EXISTS(
 if schedule['jexid']:
 idx = 0
 for exc in schedule['jexid']:
+# Convert datetime.time object to string
+if isinstance(schedule['jextime'][idx], time):
+schedul

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

2020-04-15 Thread Neel Patel
Hi,

I think we should remove the type cast from query during update and
whatever error is thrown should be shown to UI as per scenario 3.

Thanks,
Neel Patel

On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>>
>>
>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Navnath,
>>>
>>> You have compared the column's internal size with the length of the
>>> value given by the user.
>>> For example, column having integer would have internal size 4 and if I
>>> give the value 12121 which is the correct input for the field will fail
>>> here because as per your logic column internal size (4) < len(value) (5).
>>>
>>> I think this implementation is not correct here.
>>>
>> Yes, my implementations might be wrong.
>>
>> Below are some important findings on the parameterised query(as we are
>> using Jinja templates for building SQL queries).
>> Here I have created a table 'account' with some records in it.
>> CREATE TABLE public.account
>> (
>> user_id integer NOT NULL,
>> username character varying(5)
>> )
>>
>> psycopg2 throws a proper error if I pass username value greater than the
>> length of the data type(5)
>> Now, I want to pass username value greater than data type length (5)
>>
>> Scenario 1:  Query with data type and length
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> It will save the record with 5 char data without any error.
>>
>> *psql output:*
>>
>> postgres=# select * from public.account;
>>  user_id | username
>> -+--
>>1 | usern
>> (1 row)
>>
>> Scenario 2:  Query with only data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> data will not save in the table.
>>
>> We can consider scenario 2  as it will throw the valid exception and also
> typecast the value in the proper format.
>
>> Scenario 3:  Query without data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
>> user_id = 1;", {"username": "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> again data will not save in the table.
>>
>> These are some different behaviours with psycopg2. So to complete this patch 
>> which apporach should I follow? or any new approach is also welcome.
>>
>> Thanks!
>>
>>
>>
>>>
>>> Thanks,
>>> Khushboo
>>>
>>>
>>>
>>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
>>>> Hello Hackers,
>>>> Please find the attached patch for below fixes:
>>>>
>>>> - Added validation for table row data that should not be larger
>>>> than the field size.
>>>> - Rearrange the existing functions to add validation.
>>>> - Added test cases.
>>>>
>>>> Regards,
>>>> Navnath Gadakh
>>>>
>>>>
>>
>> --
>> Regards,
>> Navnath Gadakh
>>
>


Re: Proposal: Drop support for Internet Explorer

2020-04-14 Thread Neel Patel
Hi Dave,

Looks like patch is missing in attachment.

Thanks,
Neel Patel


On Tue 14 Apr, 2020, 6:53 PM Dave Page,  wrote:

> Here's an updated patch that gives a slightly different message if the
> browser is unknown vs. unsupported/deprecated. As with the previous patch,
> the check can be disabled in the config.
>
> On Fri, Apr 10, 2020 at 5:07 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Thu, Apr 9, 2020 at 11:57 PM Darren Duncan 
>> wrote:
>>
>>> The patch looks good as much as I understand it, but this raises an
>>> important
>>> question:
>>>
>>> How should one best handle minority browsers that may be completely
>>> modern but
>>> you may not specifically know about them?  Such as the newer crop of
>>> browsers
>>> that emphasize stronger privacy or may have fewer identifiers?
>>>
>>> While going on a whitelist as the patch essentially does for known good
>>> browsers
>>> is conservative, I feel that an alteration would be good.
>>>
>>> I propose dividing the browsers/environments into 3 categories, which
>>> are
>>> recognized-supported, recognized-unsupported, and unrecognized.
>>>
>>
>>> So the unsupported older versions of supported browsers get a stronger
>>> message
>>> encouraging a browser switch as they are recognized as unsupported,
>>> while
>>> unrecognized browsers get a different weaker message saying they weren't
>>> recognized so we can't determine if they'd work; both can point to the
>>> list of
>>> known supported browsers.
>>>
>>> I do agree with this suggestion.
>>
>>
>>> Related to this, there could be an application toggle that affects the
>>> unrecognized category where users can basically say, yes I understand
>>> you don't
>>> recognize this browser, please hide the warning, or something like that.
>>>
>>> Also, it probably goes without saying, but the code/templates will need
>>> to be
>>> structured in such a way that the warning message uses about plain as
>>> possible
>>> HTML so that if the browser doesn't support displaying the UI in general
>>> it can
>>> at least display the message.
>>>
>>> -- Darren Duncan
>>>
>>> On 2020-04-09 4:36 a.m., Dave Page wrote:
>>> > Hi
>>> >
>>> > On Thu, Apr 9, 2020 at 12:26 AM Darren Duncan wrote:
>>> >
>>> > If its hard to know how many people are actually using Internet
>>> Explorer:
>>> >
>>> > You could make the next release of pgAdmin display a message
>>> occasionally to
>>> > users of Internet Explorer saying that Internet Explorer will no
>>> longer be
>>> > officially supported in a future version, and when that version
>>> comes the
>>> > message says now no longer supported.
>>> >
>>> > You can then see how many people contact you about this to express
>>> concern.
>>> >
>>> >
>>> > Good idea. I've hacked up a patch to warn users if they're using a
>>> deprecated or
>>> > unsupported browser.
>>> >
>>> > CCing Akshay for a review :-)
>>> >
>>> > --
>>> > 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
>


[Patch]: Typo in 'test_config.json.in' file

2020-04-13 Thread Neel Patel
Hi,

Fix the typo in the test configuration json file while running the test
cases. Currently if someone uses the latest file to run the test cases, it
will fail to run.

Please find the attached patch.

Thanks,
Neel Patel


test_config.patch
Description: Binary data


[pgAdmin4][Runtime][Patch]: RM-4864 - Window too small for text in configuration

2020-04-12 Thread Neel Patel
Hi,

Please find an attached patch to fix the issue in the configuration window
in runtime where control where not auto resize and visible when the user
resizes the dialog.

Do review it and let me know for comments.

Thanks,
Neel Patel
diff --git a/runtime/ConfigWindow.ui b/runtime/ConfigWindow.ui
index fbdddfc2d..12770160a 100644
--- a/runtime/ConfigWindow.ui
+++ b/runtime/ConfigWindow.ui
@@ -6,7 +6,7 @@

 0
 0
-731
+975
 398

   
@@ -18,7 +18,7 @@
   
   

-625
+975
 300

   
@@ -51,7 +51,7 @@


 
- 589
+ 16777215
  16777215
 

@@ -61,6 +61,9 @@

 true

+   
+4
+   
   
  
  
@@ -123,6 +126,9 @@

 Qt::Vertical

+   
+QSizePolicy::Fixed
+   

 
  20
@@ -249,6 +255,9 @@

 Qt::Vertical

+   
+QSizePolicy::Fixed
+   

 
  20
@@ -304,6 +313,19 @@

   
  
+ 
+  
+   
+Qt::Vertical
+   
+   
+
+ 20
+ 40
+
+   
+  
+ 
 

   
@@ -312,21 +334,11 @@
   
Python
   
-  
-   
-
+  
+   
+
  
-  
-   
-The options below are intended for expert users only, and may not behave as expected as they modify fixed search paths and are not alternate values. Modify with care!
-   
-   
-true
-   
-  
- 
- 
-  
+  

 Qt::Vertical

@@ -336,89 +348,240 @@

 
  20
- 5
+ 13
 

   
  
  
-  
-   
-
- 
-  Qt::Vertical
- 
- 
-  QSizePolicy::Expanding
+  
+   
+
+ 
+  
+   0
+   0
+  
  
- 
+ 
   
-   20
-   60
+   450
+   28
   
  
-
-   
-   
-
- 
-  Python Path
- 
-
-   
-   
-
  
-  Enter the path to the directory containing pgAdmin.py if desired.
+  The options below are intended for expert users only, and may not behave as expected as they modify fixed search paths and are not alternate values. Modify with care!
  
-
-   
-   
-
- 
-  /usr/pgadmin4/lib/python2.7;/usr/pgadmin4/lib/python2.7/site-packages
+ 
+  true
  
 

-   
-
- 
-  /usr/pgadmin4/web
- 
-
+  
+ 
+ 
+  
+   
+Qt::Vertical
+   
+   
+QSizePolicy::Fixed
+   
+   
+
+ 17
+ 13
+
+   
+  
+ 
+ 
+  
+   
+
+ 
+  
+   
+
+ 50
+ 20
+
+   
+   
+Qt::LeftToRight
+   
+   
+Python Path
+   
+   
+true
+   
+   
+0
+   
+  
+ 
+ 
+  
+   
+Qt::Vertical
+   
+   
+QSizePolicy::Fixed
+   
+   
+
+ 20
+ 40
+
+   
+  
+ 
+

-   
-
- 
-  Application Path
- 
-
+   
+
+ 
+  
+   
+/usr/pgadmin4/lib/python2.7;/usr/pgadmin4/lib/python2.7/site-packages
+   
+  
+ 
+ 
+  
+   
+
+ 0
+ 0
+
+   
+   
+
+ 300
+ 20
+
+   
+   
+Enter

Re: PgAgent leap year problem

2020-03-03 Thread Neel Patel
Hi Ashesh,

I have reviewed it and looks good.  I have updated the sql version in
header of each sql file.

Thanks,
Neel Patel

On Wed, Mar 4, 2020 at 12:22 PM Ashesh Vashi 
wrote:

> On Wed, Mar 4, 2020 at 10:53 AM Neel Patel 
> wrote:
>
>> Hi Mehmet,
>>
>> It was a bug in pgAgent. Thank you for sharing the patch. I have reviewed
>> and tested, it is working fine.
>>
>> Dave/Ashesh:-  Can we commit this patch ?
>>
> Mehmet,
>
> Thanks for your patch.
> Changes look good except it does not take care of the upgrade scenarios.
>
> Hence - updated the patch for the same.
>
> Neel,
>
> Would you please review the updated patch with the upgrade scenarios?
>
>
> -- Thanks, Ashesh
>
>>
>> Thanks,
>> Neel Patel
>>
>> On Mon, Mar 2, 2020 at 5:26 PM Mehmet Emin KARAKAŞ 
>> wrote:
>>
>>> Hi,
>>>
>>> Scheduled tasks set as the last day of February this year did not work.
>>> In your schedule function have a small bug.  Leap year function get year
>>> parameter, but your code is sending day as a parameter.  Fixing patch
>>> attached in this mail.
>>>
>>> Best Regards...
>>>
>>> --
>>> MEHMET EMİN KARAKAŞ
>>> PostgreSQL DBA
>>>
>>> Turksat Satellite Communication and Cable TV Operations
>>> Konya Yolu 40. Km. 06839 Golbasi / ANKARA - TÜRKİYE
>>> Tel :  +90 312 615 32 73
>>> Faks  :  +90 312 615 32 77
>>>
>>


pgagent_leap_year_v2.patch
Description: Binary data


Re: PgAgent leap year problem

2020-03-03 Thread Neel Patel
Hi Mehmet,

It was a bug in pgAgent. Thank you for sharing the patch. I have reviewed
and tested, it is working fine.

Dave/Ashesh:-  Can we commit this patch ?

Thanks,
Neel Patel

On Mon, Mar 2, 2020 at 5:26 PM Mehmet Emin KARAKAŞ 
wrote:

> Hi,
>
> Scheduled tasks set as the last day of February this year did not work. In
> your schedule function have a small bug.  Leap year function get year
> parameter, but your code is sending day as a parameter.  Fixing patch
> attached in this mail.
>
> Best Regards...
>
> --
> MEHMET EMİN KARAKAŞ
> PostgreSQL DBA
>
> Turksat Satellite Communication and Cable TV Operations
> Konya Yolu 40. Km. 06839 Golbasi / ANKARA - TÜRKİYE
> Tel :  +90 312 615 32 73
> Faks  :  +90 312 615 32 77
>


Re: RM5049 Patch

2020-01-15 Thread Neel Patel
Patch only covers removal of the code and change in "coveragerc.in". I
guess you missed to add the new files in the patch. Can you please verify ?

Thanks,
Neel Patel

On Wed, Jan 15, 2020 at 1:16 PM Yogesh Mahajan <
yogesh.maha...@enterprisedb.com> wrote:

> Hi,
>
> Please find attached patch for  api tests for cast node.This covers -
> Added new file (cast_test_cases.json) storing inventory, test, expected
> data.
> Also covers test cases for all cast node related api,
> This increase code coverage for cast from 33% to 68%.
>
> Command to run tests -
> --pkg browser.server_groups.servers.databases.casts.tests
>
> Thanks,
> Yogesh Mahajan
> QA - Team
> EnterpriseDB Corporation
>
> Phone: +91-9741705709
>


Re: RM 4463 - MSQL test cases for domain node

2019-09-02 Thread Neel Patel
Hi,

Please find attached updated patch. I have tested with PG 9.4, PG 10 & EPAS
10.
Do review it and let me know in case of any failures.

Thanks,
Neel Patel

On Fri, Aug 23, 2019 at 1:52 PM Dave Page  wrote:

> Hi
>
> On Wed, Aug 21, 2019 at 8:58 AM Neel Patel 
> wrote:
>
>> Hi,
>>
>> Please find attached patch that will add more resql test cases and msql
>> test cases for domain node.
>>
>>- Covered test cases for Length, Precision and Collation.
>>- Also added msql test cases.
>>
>> While writing resql test cases for domain node, I found one more issue
>> RM-4644 <https://redmine.postgresql.org/issues/4644>. I have sent
>> separate patch for the same.
>>
>
> I'm getting the following error with this patch:
>
> ==
> ERROR: runTest
> (regression.re_sql.tests.test_resql.ReverseEngineeredSQLTestCases)
> Reverse Engineered SQL Test Cases
> --
> Traceback (most recent call last):
>   File
> "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line
> 126, in runTest
> self.execute_test_case(scenarios)
>   File
> "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line
> 204, in execute_test_case
> if not self.check_msql(scenario, object_id):
>   File
> "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line
> 329, in check_msql
> object_id)
>   File
> "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line
> 178, in get_url
> object_url = url_for(rule.endpoint, **options)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/helpers.py",
> line 356, in url_for
> return appctx.app.handle_url_build_error(error, endpoint, values)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/app.py",
> line 2061, in handle_url_build_error
> reraise(exc_type, exc_value, tb)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/_compat.py",
> line 35, in reraise
> raise value
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/helpers.py",
> line 345, in url_for
> force_external=external)
>   File
> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/werkzeug/routing.py",
> line 1776, in build
> raise BuildError(endpoint, values, method, self)
> werkzeug.routing.BuildError: Could not build url for endpoint
> 'NODE-domain.msql_id' with values ['did', 'gid', 'scid', 'sid']. Did you
> forget to specify values ['doid']?
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


RM_4463_V3.patch
Description: Binary data


Re: RM 4463 - RESQL test cases for domain node

2019-08-21 Thread Neel Patel
Hi,

Please find attached patch that will add more resql test cases for domain
node.

   - Covered test cases for Length, Precision and Collation.
   - Also added msql test cases.

While writing resql test cases for domain node, I found one more issue
RM-4644 <https://redmine.postgresql.org/issues/4644>. I am sending separate
patch for the same.

Thanks,
Neel Patel

On Fri, Jul 12, 2019 at 7:10 PM Dave Page  wrote:

> Thanks, applied.
>
> On Fri, Jul 12, 2019 at 12:31 PM Neel Patel 
> wrote:
>
>> Hi,
>>
>> Please find attached patch for reverse engineering test cases for domain
>> node ( RM #4463 )
>> Do review it and let me know for comments.
>>
>> Thanks,
>> Neel Patel
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


RM_4463_v2.patch
Description: Binary data


RM 4463 - MSQL test cases for domain node

2019-08-21 Thread Neel Patel
Hi,

Please find attached patch that will add more resql test cases and msql
test cases for domain node.

   - Covered test cases for Length, Precision and Collation.
   - Also added msql test cases.

While writing resql test cases for domain node, I found one more issue
RM-4644 <https://redmine.postgresql.org/issues/4644>. I have sent separate
patch for the same.

Thanks,
Neel Patel


RM_4463_v2.patch
Description: Binary data


[Patch]: RM-4644 - Length and Precision control for domain node

2019-08-21 Thread Neel Patel
Hi,

Please find attached patch to fix RM-4644 - Length and Precision control
should enable/disable based on change in data type.

Do review it and let me know for comment.

Thanks,
Neel Patel


RM-4644.patch
Description: Binary data


RM 4463 - RESQL test cases for domain node

2019-07-12 Thread Neel Patel
Hi,

Please find attached patch for reverse engineering test cases for domain
node ( RM #4463 )
Do review it and let me know for comments.

Thanks,
Neel Patel


RM_4463.patch
Description: Binary data


Re: Minor patch to fix reggression of select2 option

2019-04-30 Thread Neel Patel
Hi Dave,

RM is 4218 <https://redmine.postgresql.org/issues/4218>

Thanks,
Neel Patel

On Tue, Apr 30, 2019 at 1:25 PM Dave Page  wrote:

> Hi
>
> What's the RM for this?
>
> On Tue, Apr 30, 2019 at 8:00 AM Neel Patel 
> wrote:
>
>> Hi Team,
>>
>> Please find attached patch to fix the issue where we should properly
>> assigned 'dropdownParent'  select2 options.
>>
>> This was regression of commit 6016a5ee989a8f3f56c4a03994eb57989c3c0717
>>
>> Do review it and let us know for comments.
>>
>> Thanks,
>> Neel Patel
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


[Patch]: Minor change in dependency_inventory file to generate library file

2019-02-18 Thread Neel Patel
Hi,

Please find attached patch to handle JSON object properly to avoid error
like "the JSON object must be str, not 'bytes'" while generating
library.txt file.

Verified with both python2 and python3. Do review it and let me know for
comments.

Thanks,
Neel Patel

-- 
 <https://postgresvision.com/>
 <https://postgresvision.com/>


dependency_inventory_decode.patch
Description: Binary data


Re: pgAdmin 3.0 builds

2018-04-10 Thread Neel Patel
Hi,

On Tue, Apr 10, 2018 at 5:44 PM, Dave Page  wrote:

>
>
> On Tue, Apr 10, 2018 at 1:02 PM, Fahar Abbas  > wrote:
>
>> Yes Akshay is not able to reproduce this issue on VMWare Fusion 6.0.6
>> while Khushboo is facing same issue on Windows 07 64.
>>
>> I am using VMware Fusion 10 version and facing issue on Windows 2012 and
>> Windows 07 64 bit.
>>
>
> I also cannot reproduce it in Windows 10, Windows 7 or Windows 2008r2 on
> VMware Fusion 8.5.10.
>
> Can anyone else test on Windows please?
>

Working fine on my windows 10.


>
>>
>> Kindly suggest, how i can proceed further on this, should we document
>> this?
>>
>
> Ignore it for now. I'm far from convinced that it's not something odd with
> your VMs.
>
>
>>
>>
>>
>> On Tue, Apr 10, 2018 at 4:55 PM, Dave Page  wrote:
>>
>>>
>>>
>>> On Tue, Apr 10, 2018 at 12:54 PM, Fahar Abbas <
>>> fahar.ab...@enterprisedb.com> wrote:
>>>
 Hi Dave,

 I am still able to reproduce pgadmin4 crash issue on Windows 07 64 and
 Windows 2012 R2 64 on fresh VMs:

 https://redmine.postgresql.org/issues/3227

>>>
>>> Did you ever correlate it to VMware versions as I asked last week?
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>>
>> --
>> Fahar Abbas
>> QMG
>> EnterpriseDB Corporation
>> Phone Office: +92-51-835-8874
>> Phone Direct: +92-51-8466803
>> Mobile: +92-333-5409707
>> Skype ID: syed.fahar.abbas
>> Website: www.enterprisedb.com
>>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: Building releases...

2018-04-09 Thread Neel Patel
On Mon, Apr 9, 2018 at 6:51 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Mon, Apr 9, 2018 at 2:20 PM, Neel Patel <neel.pa...@enterprisedb.com>
> wrote:
>
>> Hi Dave,
>>
>> On Mon, Apr 9, 2018 at 6:33 PM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Mon, Apr 9, 2018 at 6:19 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> Oh yeah - I forgot to mention that running it in PyCharms seems to
>>>> work. The issue comes when using the runtime from what I can see (even
>>>> using the exact same venv that works otherwise).
>>>>
>>>> Didn't try on windows. Let me try.
>>>
>>>> On Mon, Apr 9, 2018 at 1:46 PM, Murtuza Zabuawala <
>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>
>>>>> Did not try running pgAdmin4 on windows from git repo.
>>>>> Let me get the latest pull and check.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Murtuza Zabuawala
>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>>
>>>>> On Mon, Apr 9, 2018 at 5:53 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>>>
>>>>>> ... is really not going well today.
>>>>>>
>>>>>> After arguing with PIP on Mac for some time, I eventually managed to
>>>>>> get a build out. That required a manual update of my system to 9.0.3 to
>>>>>> ensure TLS 1.2 worked, and then changing to build such that we only force
>>>>>> our own build of Psycopg2, and not other Python packages. I *think* these
>>>>>> issues are related to the whole PyPi TLS 1.2/PIP 9.0.3 brownouts and 
>>>>>> other
>>>>>> works they've been doing.
>>>>>>
>>>>>> The Windows build is a whole other ballgame. The build itself runs
>>>>>> just fine, but we end up with the following error in the log:
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>   File "C:/Program Files/pgAdmin 4/v3/web/pgAdmin4.py", line 70, in
>>>>>> 
>>>>>> app = create_app()
>>>>>>   File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\__init__.py", line
>>>>>> 367, in create_app
>>>>>> driver.init_app(app)
>>>>>>   File "C:\Program Files\pgAdmin 
>>>>>> 4\v3\web\pgadmin\utils\driver\__init__.py",
>>>>>> line 40, in init_app
>>>>>> DriverRegistry.load_drivers()
>>>>>>   File "C:\Program Files\pgAdmin 
>>>>>> 4\v3\web\pgadmin\utils\driver\registry.py",
>>>>>> line 88, in load_drivers
>>>>>> module = import_module(module_name)
>>>>>>   File "C:/Program Files/pgAdmin 4/v3/venv\lib\importlib\__init__.py",
>>>>>> line 37, in import_module
>>>>>> __import__(name)
>>>>>>   File "C:\Program Files\pgAdmin 
>>>>>> 4\v3\web\pgadmin\utils\driver\psycopg2\__init__.py",
>>>>>> line 26, in 
>>>>>> from .connection import Connection
>>>>>>   File "C:\Program Files\pgAdmin 
>>>>>> 4\v3\web\pgadmin\utils\driver\psycopg2\connection.py",
>>>>>> line 25, in 
>>>>>> from pgadmin.utils.crypto import decrypt
>>>>>>   File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\crypto.py",
>>>>>> line 16, in 
>>>>>> from Crypto.Cipher import AES
>>>>>>   File "C:/Program Files/pgAdmin 
>>>>>> 4/v3/venv/Lib/site-packages\Crypto\Cipher\__init__.py",
>>>>>> line 3, in 
>>>>>> from Crypto.Cipher._mode_ecb import _create_ecb_cipher
>>>>>>   File "C:/Program Files/pgAdmin 
>>>>>> 4/v3/venv/Lib/site-packages\Crypto\Cipher\_mode_ecb.py",
>>>>>> line 46, in 
>>>>>> """
>>>>>>   File "C:/Program Files/pgAdmin 
>>>>>> 4/v3/venv/Lib/site-packages\Crypto\Util\_raw_api.py",
>>>>>> line 258, in load_pycryptodome_raw_lib
>>>>>> raise OSError("Cannot load native module '%s': %s" % (name, ",
>>>>>> ".join(attempts)))
>>>>>> OSError: Cannot load native module 'Crypto.Cipher._raw_ecb': Trying
>>>>>> '_raw_ecb.pyd': [Error 126] The specified module could not be found
>>>>>> Exception KeyError: KeyError(3644,) in >>>>> 'C:/Program Files/pgAdmin 4/v3/venv\lib\threading.py'> ignored
>>>>>>
>>>>>> The module does exist of course in the Crypto\Cipher directory.
>>>>>>
>>>>>
>> Everything works fine on my windows machine with Python 3.5.
>> Any specific scenarios ?
>>
>
> Standard release build using Python 2.7;
>
> make x86
>
Let me try with Python 2.7 x86.


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: Building releases...

2018-04-09 Thread Neel Patel
Hi Dave,

On Mon, Apr 9, 2018 at 6:33 PM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Apr 9, 2018 at 6:19 PM, Dave Page  wrote:
>
>> Oh yeah - I forgot to mention that running it in PyCharms seems to work.
>> The issue comes when using the runtime from what I can see (even using the
>> exact same venv that works otherwise).
>>
>> Didn't try on windows. Let me try.
>
>> On Mon, Apr 9, 2018 at 1:46 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Did not try running pgAdmin4 on windows from git repo.
>>> Let me get the latest pull and check.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> On Mon, Apr 9, 2018 at 5:53 PM, Dave Page  wrote:
>>>
 ... is really not going well today.

 After arguing with PIP on Mac for some time, I eventually managed to
 get a build out. That required a manual update of my system to 9.0.3 to
 ensure TLS 1.2 worked, and then changing to build such that we only force
 our own build of Psycopg2, and not other Python packages. I *think* these
 issues are related to the whole PyPi TLS 1.2/PIP 9.0.3 brownouts and other
 works they've been doing.

 The Windows build is a whole other ballgame. The build itself runs just
 fine, but we end up with the following error in the log:

 Traceback (most recent call last):
   File "C:/Program Files/pgAdmin 4/v3/web/pgAdmin4.py", line 70, in
 
 app = create_app()
   File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\__init__.py", line
 367, in create_app
 driver.init_app(app)
   File "C:\Program Files\pgAdmin 
 4\v3\web\pgadmin\utils\driver\__init__.py",
 line 40, in init_app
 DriverRegistry.load_drivers()
   File "C:\Program Files\pgAdmin 
 4\v3\web\pgadmin\utils\driver\registry.py",
 line 88, in load_drivers
 module = import_module(module_name)
   File "C:/Program Files/pgAdmin 4/v3/venv\lib\importlib\__init__.py",
 line 37, in import_module
 __import__(name)
   File "C:\Program Files\pgAdmin 
 4\v3\web\pgadmin\utils\driver\psycopg2\__init__.py",
 line 26, in 
 from .connection import Connection
   File "C:\Program Files\pgAdmin 
 4\v3\web\pgadmin\utils\driver\psycopg2\connection.py",
 line 25, in 
 from pgadmin.utils.crypto import decrypt
   File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\crypto.py",
 line 16, in 
 from Crypto.Cipher import AES
   File "C:/Program Files/pgAdmin 
 4/v3/venv/Lib/site-packages\Crypto\Cipher\__init__.py",
 line 3, in 
 from Crypto.Cipher._mode_ecb import _create_ecb_cipher
   File "C:/Program Files/pgAdmin 
 4/v3/venv/Lib/site-packages\Crypto\Cipher\_mode_ecb.py",
 line 46, in 
 """
   File "C:/Program Files/pgAdmin 
 4/v3/venv/Lib/site-packages\Crypto\Util\_raw_api.py",
 line 258, in load_pycryptodome_raw_lib
 raise OSError("Cannot load native module '%s': %s" % (name, ",
 ".join(attempts)))
 OSError: Cannot load native module 'Crypto.Cipher._raw_ecb': Trying
 '_raw_ecb.pyd': [Error 126] The specified module could not be found
 Exception KeyError: KeyError(3644,) in >>> 'C:/Program Files/pgAdmin 4/v3/venv\lib\threading.py'> ignored

 The module does exist of course in the Crypto\Cipher directory.

>>>
Everything works fine on my windows machine with Python 3.5.
Any specific scenarios ?


>
 Murtuza, Khushboo; have you got it running on pgAdmin recently?


 --
 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
>>
>
>


Re: pgAdmin 4 commit: Fix a number of broken connection detection scenarios

2018-04-05 Thread Neel Patel
Thanks,
RM#3249 created for the same.

Regards,
Neel Patel

On Thu, Apr 5, 2018 at 11:27 AM, Akshay Joshi <akshay.jo...@enterprisedb.com
> wrote:

> Hi Neel
>
> This issue is not due to the above fix, if you can see the error it is
> showing in dashboard.js line no 454 "err = JSON.parse(xhr.responseText);"
> that code is from long time.
> I have just added an extra check of the readyState in case of server is
> down in the above commit.
> Though it is a bug can you please create a new RM for this.
>
> On Thu, Apr 5, 2018 at 10:52 AM, Neel Patel <neel.pa...@enterprisedb.com>
> wrote:
>
>> Hi Akshay,
>>
>> Due to above commit, when user "Drop" any database it gives exception in
>> browser console.
>> Check attached screenshot.
>>
>> Thanks,
>> Neel Patel
>>
>>
>>
>> On Wed, Mar 21, 2018 at 2:08 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> Fix a number of broken connection detection scenarios.
>>>
>>> Branch
>>> --
>>> master
>>>
>>> Details
>>> ---
>>> https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdif
>>> f;h=637f3b9d1a54df8b9a1bfad9e26f27fdea407683
>>> Author: Akshay Joshi <akshay.jo...@enterprisedb.com>
>>>
>>> Modified Files
>>> --
>>> web/pgadmin/dashboard/static/js/dashboard.js   | 58
>>> 
>>> web/pgadmin/static/js/sqleditor/execute_query.js   | 62
>>> +++--
>>> .../js/sqleditor/is_new_transaction_required.js|  9 
>>> web/pgadmin/tools/sqleditor/__init__.py|  4 +-
>>> web/pgadmin/tools/sqleditor/static/js/sqleditor.js | 20 ---
>>> .../tools/sqleditor/tests/test_start_query_tool.py |  2 +-
>>> .../tools/sqleditor/utils/start_running_query.py   | 63
>>> ++
>>> .../utils/tests/test_start_running_query.py| 15 +-
>>> .../user_management/static/js/user_management.js   | 13 -
>>> .../utils/driver/psycopg2/server_manager.py|  1 +
>>> .../javascript/sqleditor/execute_query_spec.js | 48
>>> -
>>> .../sqleditor/is_new_transaction_required_spec.js  | 14 ++---
>>> 12 files changed, 195 insertions(+), 114 deletions(-)
>>>
>>>
>>
>
>
> --
> *Akshay Joshi*
>
> *Sr. Software Architect *
>
>
>
> *Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
>


Re: [pgAdmin4]: Fix for RM #3248

2018-04-05 Thread Neel Patel
Hi,

Please find updated patch after fixing the comments.
Review it and let me know for comments.

Thanks,
Neel Patel

On Thu, Apr 5, 2018 at 11:32 AM, Neel Patel <neel.pa...@enterprisedb.com>
wrote:

> Thanks Murtuza & Khushboo.
> I will send updated patch.
>
> Thanks,
> Neel Patel
>
> On Thu, Apr 5, 2018 at 11:29 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Neel,
>>
>> Add below code to the top (around line no 8) in
>> alertify.pgadmin.defaults.js file will solve the problem.
>>
>> alertify.defaults.closable = false;
>>
>>
>> Thanks,
>> Khushboo
>>
>> On Thu, Apr 5, 2018 at 11:13 AM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi Neel,
>>>
>>> Can we make the change in wrapper instead of changing every where?
>>> File: ../web/pgadmin/static/js/alertify.pgadmin.defaults.js
>>>
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> On Thu, Apr 5, 2018 at 11:04 AM, Neel Patel <neel.pa...@enterprisedb.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached patch for the fix of RM #3248 - we have modified
>>>> alertify confirm dialog to modal dialog.
>>>>
>>>> Do review it and let me know for comments.
>>>>
>>>> Thanks,
>>>> Neel Patel
>>>>
>>>
>>>
>>
>


RM_3248_v2.patch
Description: Binary data


Re: [pgAdmin4]: Fix for RM #3248

2018-04-05 Thread Neel Patel
Thanks Murtuza & Khushboo.
I will send updated patch.

Thanks,
Neel Patel

On Thu, Apr 5, 2018 at 11:29 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Neel,
>
> Add below code to the top (around line no 8) in
> alertify.pgadmin.defaults.js file will solve the problem.
>
> alertify.defaults.closable = false;
>
>
> Thanks,
> Khushboo
>
> On Thu, Apr 5, 2018 at 11:13 AM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi Neel,
>>
>> Can we make the change in wrapper instead of changing every where?
>> File: ../web/pgadmin/static/js/alertify.pgadmin.defaults.js
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Thu, Apr 5, 2018 at 11:04 AM, Neel Patel <neel.pa...@enterprisedb.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Please find attached patch for the fix of RM #3248 - we have modified
>>> alertify confirm dialog to modal dialog.
>>>
>>> Do review it and let me know for comments.
>>>
>>> Thanks,
>>> Neel Patel
>>>
>>
>>
>


[pgAdmin4]: Fix for RM #3248

2018-04-04 Thread Neel Patel
Hi,

Please find attached patch for the fix of RM #3248 - we have modified
alertify confirm dialog to modal dialog.

Do review it and let me know for comments.

Thanks,
Neel Patel


RM_3248.patch
Description: Binary data


Re: Showstopper desktop runtime issue

2018-03-22 Thread Neel Patel
Hi,

On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:

> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>

As per our previous efforts on Qt's web rendering framework, I am not in
favor of adding it again as it add lots of dependency and complexity.
I would suggest to go for option 2 - To re-work the current runtime code
and find out how to get already running instance of pgadmin4.


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: pgAdmin 4 commit: Support for external tables in GPDB. Fixes #3168

2018-03-05 Thread Neel Patel
pdb#80323#\\node.sql')

==
FAIL: runTest
(pgadmin.browser.server_groups.servers.databases.external_tables.tests.test_external_tables_view.TestExternalTablesView)
#properties When retrieving the properties of a external table and the
table exists, it return the properties and status 200
--
Traceback (most recent call last):
  File "C:\Python34\Lib\unittest\mock.py", line 1142, in patched
return func(*args, **keywargs)
  File
"C:\Projects\pgadmin4\web\pgadmin\browser\server_groups\servers\databases\external_tables\tests\test_external_tables_view.py",
line 320, in runTest
self.__test_properties()
  File "C:\Python34\Lib\unittest\mock.py", line 1142, in patched
return func(*args, **keywargs)
  File
"C:\Projects\pgadmin4\web\pgadmin\browser\server_groups\servers\databases\external_tables\tests\test_external_tables_view.py",
line 419, in __test_properties
**self.expect_render_template_called_with
  File "C:\Python34\Lib\unittest\mock.py", line 777, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: Expected call:
render_template(template_name_or_list='sql/#gpdb#80323#/get_table_information.sql',
table_oid=11)
Actual call:
render_template(template_name_or_list='sql/#gpdb#80323#\\get_table_information.sql',
table_oid=11)

--
Ran 256 tests in 77.123s

FAILED (failures=7, errors=4, skipped=25)

==
Test Result Summary
==

PostgreSQL 9.6:

234 tests passed
3 tests failed:
TestExternalTablesView (#node When retrieving the
information about 1 external table and table does not exist, it return an
error message and status 404,
#node When retrieving the
information about 1 external table and an error happens while executing the
query, it return an internal server error and status 500,
#nodes When retrieving the nodes
and the database has 2 external tables, it return 2 child nodes and status
200,
#nodes When retrieving the
information about 1 external table and the table exists, it return external
node information and status 200,
#nodes When retrieving the nodes
and an error happens while executing the query, it return an internal
server error and status 500,
#properties When retrieving the
properties of a external table and the table exists, it return the
properties and status 200,
#nodes When retrieving the nodes
and the database does not have external tables, it return no child nodes
and status 200)
ChangePasswordTestCase (TestCase for Changing
Valid_Password)
TestTemplateCreate (When rendering GreenPlum 5.3 template,
when no distribution is present, when no primary key is present, it returns
"DISTRIBUTED RANDOMLY",
When rendering GreenPlum 5.3
template, when distribution is present, it returns "DISTRIBUTED BY (attr1,
attr2, attr4)",
When rendering GreenPlum 5.3
template, when no distribution is present, when primary key is present, it
returns "DISTRIBUTED BY (attr_primary_key)")
19 tests skipped:
ResourceGroupsGetTestCase (Get resource groups)
TableSpaceDeleteTestCase (Check Tablespace Node)
ResourceGroupsDeleteTestCase (Delete resource groups)
SynonymDeleteTestCase (Fetch synonym Node URL)
TestSSLConnection (Test for SSL connection)
PackageAddTestCase (Fetch Package Node URL)
SynonymPutTestCase (Fetch synonym Node URL)
TablespaceGetTestCase (Check Tablespace Node)
SynonymAddTestCase (Default Node URL)
PackagePutTestCase (Fetch Package Node URL)
TableAddTestCase (Create Range partitioned table with 2
partitions,
Create List partitioned table with
2 partitions)
PackageGetTestCase (Fetch Package Node URL)
PackageDeleteTestCase (Fetch Package Node URL)
TableSpaceAddTestCase (Check Tablespace Node)
ResourceGroupsAddTestCase (Add resource groups)
SynonymGetTestCase (Fetch synonym Node URL)
ResourceGroupsPutTestCase (Put resource groups)
TableSpaceUpdateTestCase (Check Tablespace Node)
    TableUpdateTestCase (Attach partition to existing ran

Re: [pgAdmin4][runtime][patch]: Fix for RM#2679

2017-11-21 Thread Neel Patel
Hi Dave,


On Tue, Nov 21, 2017 at 2:36 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Tue, Nov 21, 2017 at 9:02 AM, Neel Patel <neel.pa...@enterprisedb.com>
> wrote:
>
>> Hi Dave,
>>
>> On Mon, Nov 20, 2017 at 8:20 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> Hi
>>>
>>> On Mon, Nov 20, 2017 at 1:10 PM, Neel Patel <neel.pa...@enterprisedb.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached patch to fix RM#2679.
>>>>
>>>> *Issue:-*
>>>> Getting started links does not open second time from "Dashboard" panel
>>>> if User close runtime tab and open any URL again.
>>>>
>>>> *Analysis:-*
>>>> As in runtime Qt application, when user defined "target=_new" then
>>>> "createWindow" signal is called but when user close that new windows and
>>>> again click on link then "createWindow" signal is not getting called so
>>>> from user point view nothing will happen.
>>>>
>>>> *Solution:-*
>>>> To make it work in both runtime and web application, changed "target"
>>>> attribute to "_blank" so that "createWindow" signal will be called every
>>>> time when user click on any link.
>>>>
>>>
>>> I think this is a partial workaround for the problem. We link to
>>> external sites such as postgresql.org - what happens if that tries to
>>> open something with target="_new"? It should be expected to work as well. I
>>> think we need to fix the underlying problem, not try to work around it.
>>>
>>
>> Yes. You are right. We can implement the actual underlying problem but
>> curious to know the difference between "_blank" and "_new" target attribute.
>>
>> I didn't find any reference document for target attribute value "_new". I
>> searched below links.
>>
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/A#attr-target
>>
>> https://msdn.microsoft.com/en-us/library/system.web.ui.webco
>> ntrols.hyperlink.target(v=vs.110).aspx#Anchor_0
>> Thoughts ?
>>
>
> Hmm, interesting. So, per the spec we should be using _blank - I'll commit
> the patch to fix that.
>
Yes. We should use _blank instead of _new.

>
> That means that _new *should* work as any other named target - open it if
> it doesn't exist and navigate within it.
>
Yes - As per my knowledge, "target=_new" means URL to be opened in new
frame with name="_new".

>
> In other words, I think we still have a bug here; using _new (much like
> using, say, "foo") should still open a new tab if an earlier one has been
> closed - much as a browser would.
>
As per the docs, we should use "_blank". Do you feel we should fix in
runtime as well for _new, If yes - I can work on that.


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool

2017-11-17 Thread Neel Patel
Hi Dave,

I have tried for 350K rows with query given by you but not able to
reproduce the hang issue.
I have put some debug statement in Qt Signal's handler. Can you please
apply this debug patch and provide me console output if possible ?

Thanks,
Neel Patel

On Fri, Nov 17, 2017 at 3:13 PM, Neel Patel <neel.pa...@enterprisedb.com>
wrote:

> Hi Dave,
>
> On Fri, Nov 17, 2017 at 3:09 PM, Dave Page <dp...@pgadmin.org> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 9:36 AM, Neel Patel <neel.pa...@enterprisedb.com>
>> wrote:
>>
>>> Hi Dave,
>>>
>>> On Fri, Nov 17, 2017 at 2:42 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 17, 2017 at 8:45 AM, Neel Patel <
>>>> neel.pa...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Dave,
>>>>>
>>>>> On Thu, Nov 16, 2017 at 8:13 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Thu, Nov 16, 2017 at 1:47 PM, Neel Patel <
>>>>>> neel.pa...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Adding information.
>>>>>>>
>>>>>>> With this patch, RM#2715 should also be resolved.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Neel Patel
>>>>>>>
>>>>>>> On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel <
>>>>>>> neel.pa...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am able to reproduce the crash while downloading and save data in
>>>>>>>> CSV file from query tool.
>>>>>>>>
>>>>>>>> Please find attached updated patch with below changes after reading
>>>>>>>> Qt documentation.
>>>>>>>>
>>>>>>>>- Added new signal "readyRead". As per the Qt documentation,
>>>>>>>>this signal will be emitted when data is ready from IO channel for 
>>>>>>>> large
>>>>>>>>amount of data transfer between server and client.
>>>>>>>>- Ready read and DownloadInProgress signal is very quick in
>>>>>>>>call so we should not do large operation inside that slot because 
>>>>>>>> for
>>>>>>>>downloading big data it may possible of frequent call of those 
>>>>>>>> signals
>>>>>>>>which may cause the crash or missing data to write inside the file 
>>>>>>>> so
>>>>>>>>removed unnecessary logic from that slot.
>>>>>>>>- Fixed the crash while opening IODevice with NULL handle.
>>>>>>>>
>>>>>>>> With above changes, I have tested with same data as earlier and it
>>>>>>>> is working as expected without crashing the application.
>>>>>>>>
>>>>>>>> Do review it and let me know for comments.
>>>>>>>>
>>>>>>>
>>>>>> My first test was on Mac using Qt 5.8 with webkit, and when I
>>>>>> attempted to download the results from a 300K row query, it basically 
>>>>>> hung
>>>>>> showing the Downloading File progress indicator. It let me cancel it and
>>>>>> carried on working, but hung again the next time I tried the CSV 
>>>>>> download.
>>>>>> Each time it seems to download some data - from the same query I've seen
>>>>>> 2.8MB, 5.1MB and 1.5MB.
>>>>>>
>>>>>
>>>>> We are using "*downloadProgress*"  signal to update the progress bar
>>>>> and here we are getting "readData" as bytes but "totalData" is unknown so
>>>>> we received "totalData" as -1 because Qt doesn't know the total size of 
>>>>> the
>>>>> file we are getting from server but when we open "pgAdmin4" website in
>>>>> another link and try to download some binary or source at that time we are
>>>>> getting "totalData" as known size and we are displaying the progress bar
>>>>> corre

Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool

2017-11-17 Thread Neel Patel
Hi Dave,

On Thu, Nov 16, 2017 at 8:13 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi
>
> On Thu, Nov 16, 2017 at 1:47 PM, Neel Patel <neel.pa...@enterprisedb.com>
> wrote:
>
>> Hi,
>>
>> Adding information.
>>
>> With this patch, RM#2715 should also be resolved.
>>
>> Thanks,
>> Neel Patel
>>
>> On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel <neel.pa...@enterprisedb.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I am able to reproduce the crash while downloading and save data in CSV
>>> file from query tool.
>>>
>>> Please find attached updated patch with below changes after reading Qt
>>> documentation.
>>>
>>>- Added new signal "readyRead". As per the Qt documentation, this
>>>signal will be emitted when data is ready from IO channel for large 
>>> amount
>>>of data transfer between server and client.
>>>- Ready read and DownloadInProgress signal is very quick in call so
>>>we should not do large operation inside that slot because for downloading
>>>big data it may possible of frequent call of those signals which may 
>>> cause
>>>the crash or missing data to write inside the file so removed unnecessary
>>>logic from that slot.
>>>- Fixed the crash while opening IODevice with NULL handle.
>>>
>>> With above changes, I have tested with same data as earlier and it is
>>> working as expected without crashing the application.
>>>
>>> Do review it and let me know for comments.
>>>
>>
> My first test was on Mac using Qt 5.8 with webkit, and when I attempted to
> download the results from a 300K row query, it basically hung showing the
> Downloading File progress indicator. It let me cancel it and carried on
> working, but hung again the next time I tried the CSV download. Each time
> it seems to download some data - from the same query I've seen 2.8MB, 5.1MB
> and 1.5MB.
>

We are using "*downloadProgress*"  signal to update the progress bar and
here we are getting "readData" as bytes but "totalData" is unknown so we
received "totalData" as -1 because Qt doesn't know the total size of the
file we are getting from server but when we open "pgAdmin4" website in
another link and try to download some binary or source at that time we are
getting "totalData" as known size and we are displaying the progress bar
correctly.

Here, Qt sending the signal "downloadProgress" with unknown totalData size
as -1 so we update the progress bar with 100% so from user point of view it
looks like hang but it is downloading and writing to file at back ground.
if we apply the same patch in windows then it display running progress bar
so user can know something happening at back end side.

I think it is same as browser - if we download big size file from server
then it keep on downloading the file without displaying total size. What
should we do here ? Should we create one custom progress bar dialog with
moving cursor or something other so that user can know that activity is
doing at backend ? Thoughts ?



> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool

2017-11-16 Thread Neel Patel
Hi,

Adding information.

With this patch, RM#2715 should also be resolved.

Thanks,
Neel Patel

On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel <neel.pa...@enterprisedb.com>
wrote:

> Hi,
>
> I am able to reproduce the crash while downloading and save data in CSV
> file from query tool.
>
> Please find attached updated patch with below changes after reading Qt
> documentation.
>
>- Added new signal "readyRead". As per the Qt documentation, this
>signal will be emitted when data is ready from IO channel for large amount
>of data transfer between server and client.
>- Ready read and DownloadInProgress signal is very quick in call so we
>should not do large operation inside that slot because for downloading big
>data it may possible of frequent call of those signals which may cause the
>crash or missing data to write inside the file so removed unnecessary logic
>from that slot.
>- Fixed the crash while opening IODevice with NULL handle.
>
> With above changes, I have tested with same data as earlier and it is
> working as expected without crashing the application.
>
> Do review it and let me know for comments.
>
> Thanks,
> Neel Patel
>


[pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool

2017-11-16 Thread Neel Patel
Hi,

I am able to reproduce the crash while downloading and save data in CSV
file from query tool.

Please find attached updated patch with below changes after reading Qt
documentation.

   - Added new signal "readyRead". As per the Qt documentation, this signal
   will be emitted when data is ready from IO channel for large amount of data
   transfer between server and client.
   - Ready read and DownloadInProgress signal is very quick in call so we
   should not do large operation inside that slot because for downloading big
   data it may possible of frequent call of those signals which may cause the
   crash or missing data to write inside the file so removed unnecessary logic
   from that slot.
   - Fixed the crash while opening IODevice with NULL handle.

With above changes, I have tested with same data as earlier and it is
working as expected without crashing the application.

Do review it and let me know for comments.

Thanks,
Neel Patel


RM_2829_RM_2491.patch
Description: Binary data


[pgAdmin4][Patch]: RM#2716 - Automatic detect and fix value of "HKEY_CLASSES_ROOT\.css\Content Type"

2017-11-13 Thread Neel Patel
Hi,

Please find attached patch file with the fix of RM#2716.

*Issue:-*

In Windows OS, if registry "HKEY_CLASSES_ROOT\.css\Content Type" value is
not "text/css" then application get rendering issue and GUI is not
displayed properly.

*Solution:-*

When pgAdmin4 application starts, it checks for registry value above and it
differs from "text/css", application will change the value and notifies the
user about the same.

Do review it and let me know for comments.

Thanks,
Neel Patel


RM_2716.patch
Description: Binary data


[pgAdmin4][patch][runtime]: RM#2443 - No prompt while exiting application

2017-11-06 Thread Neel Patel
Hi,

Please find attached patch to fix RM#2443 - No prompt while existing from
main pgAdmin4 runtime browser window.

Do review it and let me know for comments.

Thanks,
Neel Patel


RM_2443.patch
Description: Binary data


Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-23 Thread Neel Patel
Hi Ashesh,

I just added condition before delete the job otherwise it looks good.
Correct me if I am wrong.

if (job != NULL)
{
delete job;
job = NULL;
}

I have created two instances of pgagent on database cluster. As of now not
able to see any leak and keep you updated if found anything.

@Robert - Can you also test at your environment and keep us updated for any
leak ?

Thanks,
Neel Patel

On Mon, Oct 23, 2017 at 10:30 AM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:

> Hi Rob,
>
> How about this?
>
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> <http://www.enterprisedb.com>
>
>
> *http://www.linkedin.com/in/asheshvashi*
> <http://www.linkedin.com/in/asheshvashi>
>
> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery <re-pg...@codeweavers.net>
> wrote:
>
>> Hi,
>>
>> Following on from https://www.postgresql.org/mes
>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>> A%40mail.gmail.com
>>
>> I think I've identified and fixed the issue, please see the patch
>> attached.
>>
>> As I understand it when there are multiple pgagent instances and they
>> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the
>> conflict's thread will never be executed (i.e. job.cpp:418
>> JobThread::Entry), which is responsible for deleting the job owned by the
>> thread, meaning that the connection is never returned to the pool. By
>> moving the delete of the job into the destructor, we can assure that the
>> connection is tidied up in both cases as the thread is deleted in the error
>> case explicitly in pgAgent.cpp:185.
>>
>> The only possibly unintended difference that I can see with doing this is
>> that the log "Completed job: %s" is now output when before it wasn't,
>> however I think this new behaviour is actually correct as the job object is
>> completed at that time.
>>
>> Thanks,
>> Rob
>>
>> <https://codeweavers.net>
>>
>>
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169=f556b0bf09>
>> Codeweavers
>> October
>>  Newsletter
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169=f556b0bf09>
>> *l  *Auto Trader extends partnership with Codeweavers
>> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
>>
>>
>> <https://codeweavers.net/automotive-vision-conference-agenda>
>>
>> *What are Codeweavers doing to gear up for GDPR?
>> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*
>>
>>
>>
>> *Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
>> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18
>> 9AB
>> Registered in England and Wales No. 04092394 | VAT registration no. 974
>> 9705 63
>>
>> <https://www.linkedin.com/company/codeweavers-limited>
>> <https://vimeo.com/codeweaversltd>  [image:
>> https://plus.google.com/b/105942302039373248738/+CodeweaversNet]
>> <https://plus.google.com/b/105942302039373248738/+CodeweaversNet>  [image:
>> https://twitter.com/CodeweaversTeam]
>> <https://twitter.com/CodeweaversTeam>
>>
>
>


connection_pool_v3.patch
Description: Binary data


Re: v2.0-rc1 not starting, runtime not building

2017-09-14 Thread Neel Patel
Hi,

I don't know the installed packages on your system but what I can help only
- Download Qt 5.5 installers from "https://download.qt.io/archive/qt/; and
install it on custom path ( e.g. /opt/Qt5.5" and use "qmake" installed in
that directory during compilation and let us know result.

Thanks,
Neel Patel

On Thu, Sep 14, 2017 at 2:32 PM, Willy-Bas Loos <willy...@gmail.com> wrote:

>
> On Thu, Sep 14, 2017 at 10:35 AM, Neel Patel <neel.pa...@enterprisedb.com>
> wrote:
>
>> Surely, there is something wrong with your Qt installation.
>> Can you please try to install required "*-dev" packages for qt5 ?
>>
>>
>> Sure, i just don't know how to find out which ones. libraies.txt only
> says "QT".
> So i have:
> qtdeclarative5-dev:amd64
> qtdeclarative5-dev-tools
> libqt5opengl5-dev:amd64
> libqt5webkit5-dev:amd64
> pyqt5-dev
> and now also pyqt5-dev-tools (doesn't change the outcome/output)
>
> all in version 5.5.1
>
> Interestingly, qmake only displays the QT warning when I add "DEFINES
> +=PGADMIN4_USE_WEBKIT"
> To me, that implies that the wrong webkit is being used. I do have a few
> packages that are similar:
>
> (pgadmin4) wbloos@wb:~/python-files/pgadmin4/runtime$ dpkg -l|grep
> webkit|cut -f 3 -d ' '
> gir1.2-webkit2-4.0:amd64
> libqt5webkit5:amd64
> libqt5webkit5-dev:amd64
> libqtwebkit4:amd64
> libqtwebkit4:i386
> libwebkit2gtk-4.0-37:amd64
> libwebkit2gtk-4.0-37-gtk2:amd64
> libwebkitgtk-3.0-0:amd64
> libwebkitgtk-3.0-common
>
> I'm not sure how they got there, i haven't tried what dependents they
> have. I could try removing them but i will probably run into some trouble.
>
> Willy-Bas Loos
>


Re: pgAdmin 4 v1.6 Released!

2017-07-13 Thread Neel Patel
Hi,


Thanks,
Neel Patel

On Jul 14, 2017 5:31 AM, "Shira Bezalel" <sh...@sfei.org> wrote:

I downloaded the Windows pgAdmin 1.6 version, and after launching it, it
simply shows a black display. My colleague also on Windows 10 had the same
experience.

Does this sound like a known problem?


It is not an issue with 1.6. This is due to previous "ActiveQt" testing
build using different zoom level.
To resolve the issue press Ctrl 0.


Shira

On Thu, Jul 13, 2017 at 11:18 AM, Lazaro Garcia <lazaro3...@gmail.com>
wrote:

> The download links are wrong, the links downloads 1.5 and not 1.6.
>
>
>
> Regards.
>
>
>
> *De:* Dave Page [mailto:dp...@pgadmin.org]
> *Enviado el:* jueves, 13 de julio de 2017 11:18 a. m.
> *Para:* pgAdmin Support; pgadmin-hackers
> *Asunto:* pgAdmin 4 v1.6 Released!
>
>
>
> The pgAdmin Development Team are pleased to announce the release of
> pgAdmin 4 version 1.6. This release of pgAdmin 4 includes over 70 bug fixes
> and a dozen new features. For details, please see the release notes (
> https://www.pgadmin.org/docs/pgadmin4/dev/release_notes_1_6.html).
>
>
>
> Notable changes in this release include:
>
>
>
> * Significant performance improvements on Windows, massively reducing
> initial load time and improving UI response for the vast majority of users
> during testing.
>
>
>
> * Enhancements to the Query Tool enabling the viewing of large query
> resultsets far more quickly. For example, a simple test query with 96K rows
> rendered results within 1 second vs. 22 seconds in pgAdmin III during
> testing!
>
>
>
> * A major rewrite of the Query History tab allows browsing of queries
> executed in the query tool with full details including the entire query, in
> a much nicer user interface.
>
>
>
> * The Desktop Runtime now supports detachable tabs, allowing the Query
> Tool and Debugger to be opened in new tabs and then moved to alternate
> displays (from 1.5 this was possible in web mode only)
>
>
>
> * The Query Tool's Results Grid has been overhauled with a new, sleek look
> an feel supporting selection of arbitrary rows, columns or blocks of cells
> with full copy support and column sizing retention.
>
>
>
> * The Dashboard tab can now be closed if desired, to minimise query
> traffic resulting from graph updates.
>
>
>
> For more information, checkout the online documentation, and of course the
> download page:
>
>
>
> Docs: https://www.pgadmin.org/docs/pgadmin4/dev/index.html
>
>
>
> Download: https://www.pgadmin.org/download
>
>
>
>
>
> --
>
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>

​


[pgAdmin4][runtime]: Fix RM #2558

2017-07-13 Thread Neel Patel
Hi,

Please find attached patch file for the fix of below issue in runtime.

  RM #2558 -  Tab bar on main window vanishes when closing child via
tab button

I have tested with all 3 platforms. Do review it and let me know for
comments.

Thanks,
Neel Patel


RM_2558.patch
Description: Binary data