[pgadmin-hackers] pgAdmin 4 commit: Using client-side implementation of 'url_for' in the

[Ashesh Vashi]

Using client-side implementation of 'url_for' in the settings module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=900ccebb50bdc448da5adad55fb513815b0a7b82

Modified Files
--
web/pgadmin/settings/__init__.py   | 34 ++
.../settings/templates/settings/settings.js| 10 ---
2 files changed, 8 insertions(+), 36 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the use

[Ashesh Vashi]

Using client-side 'url_for' implementation in the user management
module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=5c140b3f58980b6f1bba01e4ed8b7006fbd74af4

Modified Files
--
web/pgadmin/tools/user_management/__init__.py  | 30 ++--
.../user_management/js/user_management.js  | 88 +++---
2 files changed, 69 insertions(+), 49 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the imp

[Ashesh Vashi]

Using client-side 'url_for' implementation in the import/export module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=e65b605912194808a2530cc644367137240d1003

Modified Files
--
web/pgadmin/tools/import_export/__init__.py   |  9 -
.../templates/import_export/js/import_export.js   | 15 +++
2 files changed, 15 insertions(+), 9 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the mai

[Ashesh Vashi]

Using client-side 'url_for' implementation in the maintenance module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=07580b844466e55c825178ce0385c82c57dff149

Modified Files
--
web/pgadmin/tools/maintenance/__init__.py  | 11 ++-
.../templates/maintenance/js/maintenance.js| 34 +-
2 files changed, 31 insertions(+), 14 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Re: Server side cursor limitations for on demand loading of data in query tool [RM2137] [pgAdmin4]

[Ashesh Vashi]

On Wed, Jun 14, 2017 at 6:19 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi,
>
> Sorry - it's drifted out again, I suspect because of the work Ashesh
> has been doing. Can you rebase please? Check with Ashesh first though,
> in case he's about ready to commit another big change.
>
I am not. :-)

--

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>

>
> Thanks.
>
> On Fri, Jun 9, 2017 at 10:08 AM, Harshal Dhumal
> <harshal.dhu...@enterprisedb.com> wrote:
> > Hi,
> >
> >
> > Please find rebased patch
> >
> > --
> > Harshal Dhumal
> > Sr. Software Engineer
> >
> > EnterpriseDB India: http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> >
> > On Thu, Jun 8, 2017 at 6:40 PM, Harshal Dhumal
> > <harshal.dhu...@enterprisedb.com> wrote:
> >>
> >> Ignore this patch.
> >> Rebase and migration of feature tests and jasmine tests required.
> >>
> >> --
> >> Harshal Dhumal
> >> Sr. Software Engineer
> >>
> >> EnterpriseDB India: http://www.enterprisedb.com
> >> The Enterprise PostgreSQL Company
> >>
> >> On Thu, Jun 8, 2017 at 3:56 PM, Harshal Dhumal
> >> <harshal.dhu...@enterprisedb.com> wrote:
> >>>
> >>> Hi,
> >>> Please find attached updated patch for feature RM2137.
> >>>
> >>> Changes in this patch:
> >>> 1. Patch rebased.
> >>>
> >>> 2. Updated existing feature tests which requires changes due to this
> >>> feature.
> >>>  affected feature test cases:
> >>>  i. PGDataypeFeatureTest
> >>>  ii. CheckForXssFeatureTest
> >>>
> >>> 3. Updated existing jasmine test cases which requires changes due to
> this
> >>> feature.
> >>>  affected jasmine test cases:
> >>>  i. copy data
> >>>  ii. range_boundary_navigator
> >>>  iii. row_selector
> >>>  iv. set_stages_rows
> >>>
> >>> 4. New feature tests added
> >>> i. on demand result set on scrolling.
> >>> ii. on demand result set on grid select all.
> >>> iii. on demand result set on column select all.
> >>> iv. explain query
> >>> v. explain query with verbose
> >>> vi. explain query with costs
> >>> vii. explain analyze query
> >>> viii. explain analyze query with buffers
> >>> ix. explain analyze query with timing
> >>> x. auto commit disabled.
> >>> xi. auto commit enabled.
> >>> xii. auto rollback enabled.
> >>> xiii. cancel query.
> >>>
> >>>
> >>>
> >>> --
> >>> Harshal Dhumal
> >>> Sr. Software Engineer
> >>>
> >>> EnterpriseDB India: http://www.enterprisedb.com
> >>> The Enterprise PostgreSQL Company
> >>>
> >>> On Tue, May 16, 2017 at 8:14 PM, Dave Page <dp...@pgadmin.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Mon, May 15, 2017 at 7:40 PM, Harshal Dhumal
> >>>> <harshal.dhu...@enterprisedb.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Sat, May 13, 2017 at 12:35 AM, Joao Pedro De Almeida Pereira
> >>>>> <jdealmeidapere...@pivotal.io> wrote:
> >>>>>>
> >>>>>> We were only able to apply the patch on 1f903ba2 (were seeing patch
> >>>>>> does not apply due to sqleditor.js conflicts)
> >>>>>> The javascript tests passed, but we were unable to copy rows or
> >>>>>> columns or cells when running the application. Could you run
> feature tests?
> >>>>>
> >>>>> There are three modes sqleditor can be launched
> >>>>> 1. Query tool  (Tools menus -> Query Tool)
> >>>>> 2. Datagrid.  (Right click on any table/view  -> View Data -> View
> >>>>> All/First 100/Last 100/Filtered rows)
> >>>>> 3. Scripts (Right click on any table/view ->
> >>>>> INSERT/CREATE/UPDATE/DELETE/SELECT)
> >>>>>
> >>>>> Paste functionality is only enabled in Datagrid 

Re: [pgadmin-hackers] [pgAdmin4] [PATCH] History Tab rewrite in React

[Ashesh Vashi]

--

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 Tue, Jun 13, 2017 at 3:56 PM, Dave Page <dp...@pgadmin.org> wrote:

> On Tue, Jun 13, 2017 at 11:22 AM, Ashesh Vashi
> <ashesh.va...@enterprisedb.com> wrote:
> > On Tue, Jun 13, 2017 at 2:47 PM, Dave Page <dp...@pgadmin.org> wrote:
> >>
> >> And then I find a problem. Sigh.
> >>
> >> When running in the desktop runtime, under QtWekKit (the forked,
> >> updated version that is by far the best of the browser engines we've
> >> used), we get the attached error at startup. I don't see this under
> >> QtWebEngine, though as we've already found, that's not usable for
> >> other reasons.
> >>
> >> Is this fixable?
> >
> > As per 'http://qtwebkit.blogspot.in/2016/08/qtwebkit-im-back.html':
> > "
> > WebKit engine itself has not been updated since Qt 5.2 release. That's
> why
> > it didn't support recent changes in Web standards that happened after
> 2013,
> > including: new JavaScript language standard ES2015 (also known as ES6),
> as
> > well as improvements in DOM API and CSS.
> > ...
> > "
> >
> > Could this be a reason?
>
> For the old webkit, certainly, but if you read further down, the
> version we're using has been updated and does now claim to support
> most of ES2015.
>
This is in one of the comment section.

"This branch is 1099 commits ahead, 7251 commits behind WebKit:master."

-- Thanks, Ashesh

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

[pgadmin-hackers] pgAdmin 4 commit: Package 'mock' is required for testing, and for Pytho

[Ashesh Vashi]

Package 'mock' is required for testing, and for Python < 3.3 only.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=467825c2d19c1ce43e81ea34fa063ef04938c31a

Modified Files
--
requirements.txt| 1 -
web/regression/requirements.txt | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] pgAdmin 4 commit: Required mock package for python < 3.3.

[Ashesh Vashi]

On Tue, Jun 13, 2017 at 3:57 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Tue, Jun 13, 2017 at 11:25 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Tue, Jun 13, 2017 at 3:52 PM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Oops.
>>> let me revert it back.
>>>
>> 'web/regressions/requirements.txt' needs to change as it is not require
>> for Python >= 3.3.
>> Will do the change.
>>
>
> OK, thanks.
>
Done.
Thanks.

-- Thanks, Ashesh

>
>
>>
>>> --
>>>
>>> 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 Tue, Jun 13, 2017 at 3:50 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> Is mock required at runtime, or just for tests? It's already in
>>>> web/regressions/requirements.txt
>>>>
>>>> On Tue, Jun 13, 2017 at 11:13 AM, Ashesh Vashi
>>>> <ashesh.va...@enterprisedb.com> wrote:
>>>> > Required mock package for python < 3.3.
>>>> > It was required for the commit:
>>>> > 1208206bc0eca2d135469258e8a209b983e668be
>>>> >
>>>> > Also, do not fetch the scenario-name, when it is not avaiable (but -
>>>> use
>>>> > default vaule as the stringified test-case itself).
>>>> >
>>>> > Branch
>>>> > --
>>>> > master
>>>> >
>>>> > Details
>>>> > ---
>>>> > https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdif
>>>> f;h=903389d7b76046141c92a720e9e515cc4bb46274
>>>> >
>>>> > Modified Files
>>>> > --
>>>> > requirements.txt   | 3 ++-
>>>> > web/regression/runtests.py | 8 +---
>>>> > 2 files changed, 7 insertions(+), 4 deletions(-)
>>>> >
>>>> >
>>>> > --
>>>> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org
>>>> )
>>>> > To make changes to your subscription:
>>>> > http://www.postgresql.org/mailpref/pgadmin-hackers
>>>>
>>>>
>>>>
>>>> --
>>>> 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-hackers] pgAdmin 4 commit: Required mock package for python < 3.3.

[Ashesh Vashi]

On Tue, Jun 13, 2017 at 3:52 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com
> wrote:

> Oops.
> let me revert it back.
>
'web/regressions/requirements.txt' needs to change as it is not require for
Python >= 3.3.
Will do the change.

>
> --
>
> 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 Tue, Jun 13, 2017 at 3:50 PM, Dave Page <dp...@pgadmin.org> wrote:
>
>> Is mock required at runtime, or just for tests? It's already in
>> web/regressions/requirements.txt
>>
>> On Tue, Jun 13, 2017 at 11:13 AM, Ashesh Vashi
>> <ashesh.va...@enterprisedb.com> wrote:
>> > Required mock package for python < 3.3.
>> > It was required for the commit:
>> > 1208206bc0eca2d135469258e8a209b983e668be
>> >
>> > Also, do not fetch the scenario-name, when it is not avaiable (but - use
>> > default vaule as the stringified test-case itself).
>> >
>> > Branch
>> > --
>> > master
>> >
>> > Details
>> > ---
>> > https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdif
>> f;h=903389d7b76046141c92a720e9e515cc4bb46274
>> >
>> > Modified Files
>> > --
>> > requirements.txt   | 3 ++-
>> > web/regression/runtests.py | 8 +---
>> > 2 files changed, 7 insertions(+), 4 deletions(-)
>> >
>> >
>> > --
>> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

Re: [pgadmin-hackers] pgAdmin 4 commit: Required mock package for python < 3.3.

[Ashesh Vashi]

Oops.
let me revert it back.

--

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 Tue, Jun 13, 2017 at 3:50 PM, Dave Page <dp...@pgadmin.org> wrote:

> Is mock required at runtime, or just for tests? It's already in
> web/regressions/requirements.txt
>
> On Tue, Jun 13, 2017 at 11:13 AM, Ashesh Vashi
> <ashesh.va...@enterprisedb.com> wrote:
> > Required mock package for python < 3.3.
> > It was required for the commit:
> > 1208206bc0eca2d135469258e8a209b983e668be
> >
> > Also, do not fetch the scenario-name, when it is not avaiable (but - use
> > default vaule as the stringified test-case itself).
> >
> > Branch
> > --
> > master
> >
> > Details
> > ---
> > https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=
> 903389d7b76046141c92a720e9e515cc4bb46274
> >
> > Modified Files
> > --
> > requirements.txt   | 3 ++-
> > web/regression/runtests.py | 8 +---
> > 2 files changed, 7 insertions(+), 4 deletions(-)
> >
> >
> > --
> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgadmin-hackers
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] [pgAdmin4] [PATCH] History Tab rewrite in React

[Ashesh Vashi]

On Tue, Jun 13, 2017 at 2:47 PM, Dave Page  wrote:

> And then I find a problem. Sigh.
>
> When running in the desktop runtime, under QtWekKit (the forked,
> updated version that is by far the best of the browser engines we've
> used), we get the attached error at startup. I don't see this under
> QtWebEngine, though as we've already found, that's not usable for
> other reasons.
>
> Is this fixable?
>
As per 'http://qtwebkit.blogspot.in/2016/08/qtwebkit-im-back.html':
"
*WebKit engine itself has not been updated since Qt 5.2 release. That's why
it didn't support recent changes in Web standards that happened after 2013,
including: new JavaScript language standard ES2015 (also known as ES6), as
well as improvements in DOM API and CSS.*
*...*
"

Could this be a reason?

-- Thanks, Ashesh

>
> On Tue, Jun 13, 2017 at 9:52 AM, Dave Page  wrote:
> > Hi
> >
> > On Mon, Jun 12, 2017 at 7:22 PM, Shruti B Iyer  wrote:
> >> Hi Dave,
> >>
> >> We regenerated the patch to add new tasks to package.json to compile
> react
> >> code for development and to not minimize it. This should fix the error
> you
> >> captured in the screenshot.
> >>
> >> The new task to lint and bundle everything for development is:
> >> yarn run bundle:dev
> >>
> >> The new task only bundle everything is:
> >> yarn run webpacker:dev
> >>
> >> We also changed the task test:feature to bundle without optimization
> before
> >> we start the tests.
> >>
> >> When we ran these commands in our machine, they did not display any
> error.
> >> Is it possible that you forgot to run yarn install before running the
> >> webpacker task? We are asking this because the errors look like missing
> node
> >> packages.
> >
> > I did run an install, yes. This patch does work though, so applied -
> thanks!
> >
> > Could you answer my earlier question about the need for the delay in
> > app_starter.py please?
> >
> > Thanks.
> >
> >> On Mon, Jun 12, 2017 at 12:15 PM Dave Page  wrote:
> >>>
> >>> To add to that; running the JS tests gives:
> >>>
> >>> ERROR in ./regression/javascript/history/query_history_entry_spec.jsx
> >>> Module not found: Error: Can't resolve 'jasmine-enzyme' in
> >>> '/Users/dpage/git/pgadmin4/web/regression/javascript/history'
> >>>  @ ./regression/javascript/history/query_history_entry_spec.jsx
> 13:21-46
> >>>
> >>> ERROR in ./pgadmin/static/jsx/history/query_history_entry.jsx
> >>> Module not found: Error: Can't resolve 'immutability-helper' in
> >>> '/Users/dpage/git/pgadmin4/web/pgadmin/static/jsx/history'
> >>>  @ ./pgadmin/static/jsx/history/query_history_entry.jsx 13:26-56
> >>>  @ ./regression/javascript/history/query_history_entry_spec.jsx
> >>>
> >>> ERROR in ./pgadmin/static/jsx/history/query_history_entry.jsx
> >>> Module not found: Error: Can't resolve 'moment' in
> >>> '/Users/dpage/git/pgadmin4/web/pgadmin/static/jsx/history'
> >>>  @ ./pgadmin/static/jsx/history/query_history_entry.jsx 17:14-31
> >>>  @ ./regression/javascript/history/query_history_entry_spec.jsx
> >>>
> >>> ERROR in ./regression/javascript/history/query_history_spec.jsx
> >>> Module not found: Error: Can't resolve 'jasmine-enzyme' in
> >>> '/Users/dpage/git/pgadmin4/web/regression/javascript/history'
> >>>  @ ./regression/javascript/history/query_history_spec.jsx 19:21-46
> >>> webpack: Failed to compile.
> >>> PhantomJS 2.1.1 (Mac OS X 0.0.0) ERROR
> >>>   Error: Cannot find module "immutability-helper"
> >>>   at regression/javascript/history/query_history_entry_spec.jsx:30705
> >>>
> >>>
> >>> PhantomJS 2.1.1 (Mac OS X 0.0.0) ERROR
> >>>   Error: Cannot find module "immutability-helper"
> >>>   at regression/javascript/history/query_history_spec.jsx:30705
> >>>
> >>>
> >>> error Command failed with exit code 1.
> >>> info Visit https://yarnpkg.com/en/docs/cli/run for documentation about
> >>> this command.
> >>> error Command failed with exit code 1.
> >>> info Visit https://yarnpkg.com/en/docs/cli/run for documentation about
> >>> this command.
> >>>
> >>>
> >>> Also, while I think of it, why the addition of the delay to
> >>> app_starter.py?
> >>>
> >>>
> >>> On Mon, Jun 12, 2017 at 5:12 PM, Dave Page  wrote:
> >>> > Hi,
> >>> >
> >>> > So 01 and 02 are now committed :-).
> >>> >
> >>> > 03 has a couple of problems though (likely the same):
> >>> >
> >>> > - Running the webpacker results in:
> >>> >
> >>> > (pgadmin4)piranha:web dpage$ yarn run webpacker
> >>> > yarn run v0.24.4
> >>> > $ yarn run webpack -- --optimize-minimize --config webpack.config.js
> >>> > yarn run v0.24.4
> >>> > $ "/Users/dpage/git/pgadmin4/web/node_modules/.bin/webpack"
> >>> > --optimize-minimize --config webpack.config.js
> >>> > (node:19446) DeprecationWarning: loaderUtils.parseQuery() received a
> >>> > non-string value which can be problematic, see
> >>> > https://github.com/webpack/loader-utils/issues/56
> >>> > parseQuery() will be replaced with getOptions() in the next major
> >>> 

[pgadmin-hackers] pgAdmin 4 commit: Required mock package for python < 3.3.

[Ashesh Vashi]

Required mock package for python < 3.3.
It was required for the commit:
1208206bc0eca2d135469258e8a209b983e668be

Also, do not fetch the scenario-name, when it is not avaiable (but - use
default vaule as the stringified test-case itself).

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=903389d7b76046141c92a720e9e515cc4bb46274

Modified Files
--
requirements.txt   | 3 ++-
web/regression/runtests.py | 8 +---
2 files changed, 7 insertions(+), 4 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the Gra

[Ashesh Vashi]

Using client-side 'url_for' implementation in the Grant-Wizard module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0243d886c3cd01d8ca4d2941edf063c39affd1e6

Modified Files
--
web/pgadmin/tools/grant_wizard/__init__.py | 38 -
.../templates/grant_wizard/js/grant_wizard.js  | 63 +++---
2 files changed, 57 insertions(+), 44 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the bac

[Ashesh Vashi]

Using client-side 'url_for' implementation in the backup module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=4a46f7b1eb7246f34f05b1bf2a2429c2cff7ea9e

Modified Files
--
web/pgadmin/tools/backup/__init__.py| 15 +--
.../tools/backup/templates/backup/js/backup.js  | 21 +++--
2 files changed, 24 insertions(+), 12 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the res

[Ashesh Vashi]

Using client-side 'url_for' implementation in the restore module.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=f9a387822047f862b01fb62e879b071b1e3c3c00

Modified Files
--
web/pgadmin/tools/restore/__init__.py  |  8 +++-
.../tools/restore/templates/restore/js/restore.js  | 18 ++
2 files changed, 17 insertions(+), 9 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using client-side 'url_for' implementation in the mod

[Ashesh Vashi]

Using client-side 'url_for' implementation in the module - bgprocess
(background-processes).

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=1a7c9d5ca1e0d92c113b093aa5cf2c2a34092b59

Modified Files
--
web/pgadmin/misc/bgprocess/__init__.py| 22 --
web/pgadmin/misc/bgprocess/static/js/bgprocess.js | 37 ++-
2 files changed, 34 insertions(+), 25 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Using the client-side translation using the client-si

[Ashesh Vashi]

Using the client-side translation using the client-side 'gettext'
implementation.

This is the first step towards 'Avoid creating the javascript modules
using Jinja templates'.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ae809766892e3cbca3118bcaddb899b186778f12

Modified Files
--
.../databases/casts/templates/cast/js/casts.js |  62 ++--
.../templates/event_triggers/js/event_trigger.js   |  53 +--
.../templates/extensions/js/extensions.js  |  40 +--
.../foreign_servers/js/foreign_servers.js  |  43 +--
.../templates/user_mappings/js/user_mappings.js|  36 +-
.../js/foreign_data_wrappers.js|  50 +--
.../languages/templates/languages/js/languages.js  |  55 +--
.../js/catalog_object_column.js|  31 +-
.../templates/catalog_object/js/catalog_object.js  |  19 +-
.../collations/templates/collation/js/collation.js |  47 +--
.../domain_constraints/js/domain_constraints.js|  42 +--
.../domains/templates/domains/js/domains.js|  74 ++--
.../templates/foreign_tables/js/foreign_tables.js  | 119 +++
.../fts_configuration/js/fts_configuration.js  |  57 ++--
.../templates/fts_dictionary/js/fts_dictionary.js  |  54 +--
.../templates/fts_parser/js/fts_parser.js  |  58 ++--
.../templates/fts_template/js/fts_templates.js |  37 +-
.../functions/templates/function/js/functions.js   | 150 -
.../functions/templates/procedure/js/procedures.js |  29 +-
.../trigger_function/js/trigger_functions.js   | 130 +++
.../edbfuncs/templates/edbfunc/js/edbfunc.js   |  46 +--
.../edbfuncs/templates/edbproc/js/edbproc.js   |  15 +-
.../packages/edbvars/templates/edbvar/js/edbvar.js |  22 +-
.../packages/templates/package/js/package.js   |  49 +--
.../sequences/templates/sequence/js/sequence.js|  75 +++--
.../synonyms/templates/synonym/js/synonym.js   |  57 ++--
.../tables/column/templates/column/js/column.js| 102 +++---
.../check_constraint/js/check_constraint.js|  41 ++-
.../js/exclusion_constraint.js |  68 ++--
.../templates/foreign_key/js/foreign_key.js| 126 +++
.../index_constraint/js/index_constraint.js|  42 +--
.../templates/constraints/js/constraints.js|  20 +-
.../tables/indexes/templates/index/js/index.js |  92 ++---
.../tables/rules/templates/rules/js/rules.js   |  47 ++-
.../schemas/tables/templates/table/js/table.js | 189 +--
.../triggers/templates/trigger/js/trigger.js   | 115 +++
.../schemas/templates/catalog/js/catalog.js|  28 +-
.../schemas/templates/schema/js/schema.js  | 120 ---
.../schemas/types/templates/type/js/type.js| 194 +--
.../schemas/views/templates/mview/js/mview.js  |  72 ++--
.../schemas/views/templates/view/js/view.js|  62 ++--
.../databases/templates/databases/js/databases.js  | 129 ---
.../templates/pga_schedule/js/pga_schedule.js  | 375 ++---
.../steps/templates/pga_jobstep/js/pga_jobstep.js  |  80 +++--
.../pgagent/templates/pga_job/js/pga_job.js|  70 ++--
.../resource_groups/js/resource_groups.js  |  68 ++--
.../servers/roles/templates/role/js/role.js|  97 +++---
.../server_groups/servers/static/js/privilege.js   |  23 +-
.../templates/tablespaces/js/tablespaces.js|  83 ++---
.../servers/templates/servers/servers.js   | 142 
.../templates/server_groups/server_groups.js   |  19 +-
web/pgadmin/browser/static/js/node.ui.js   |  10 +-
.../browser/templates/browser/js/browser.js|  53 ++-
.../browser/templates/browser/js/collection.js |  17 +-
.../browser/templates/browser/js/messages.js   |  53 +--
web/pgadmin/browser/templates/browser/js/node.js   |  64 ++--
web/pgadmin/misc/bgprocess/__init__.py |  11 +-
web/pgadmin/misc/bgprocess/static/js/bgprocess.js  |  24 +-
web/pgadmin/misc/depends/static/js/depends.js  |  12 +-
.../templates/file_manager/js/file_manager.js  |  41 ++-
.../templates/file_manager/js/utility.js   |  11 +-
web/pgadmin/misc/sql/static/js/sql.js  |  18 +-
.../misc/statistics/static/js/statistics.js|  24 +-
.../templates/preferences/preferences.js   |  11 +-
web/pgadmin/static/js/alertify.pgadmin.defaults.js |  10 +-
web/pgadmin/static/js/backform.pgadmin.js  |  41 +--
.../tools/backup/templates/backup/js/backup.js | 226 ++---
.../datagrid/templates/datagrid/js/datagrid.js |  26 +-
.../debugger/templates/debugger/js/debugger.js |  40 +--
.../debugger/templates/debugger/js/debugger_ui.js  |  14 +-
.../tools/debugger/templates/debugger/js/direct.js |  31 +-
.../templates/grant_wizard/js/grant_wizard.js  |  30 +-
.../templates/import_export/js/import_export.js| 134 
.../templates/maintenance/js/maintenance.js|  56 +--

Re: [pgadmin-hackers] [pgAdmin4][PATCH] To fix the issue with Node rename

[Ashesh Vashi]

Sure.
I am reviewing it.

--

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 Fri, May 12, 2017 at 3:09 PM, Dave Page <dp...@pgadmin.org> wrote:

> Ashesh, can you get this in today please?
>
> Thanks.
>
> On Fri, May 12, 2017 at 7:07 AM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi Ashesh,
>>
>> As discussed please find updated patch removing hardcoded check for
>> server & server-group node.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Fri, Apr 28, 2017 at 1:29 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi Ashesh,
>>>
>>> PFA updated patch for the issue.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> On Wed, Apr 26, 2017 at 10:29 AM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
>>>>
>>>> On Mon, Apr 24, 2017 at 4:43 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>>
>>>>> Ashesh, can you review/commit this please? Thanks.
>>>>>
>>>>> On Mon, Apr 24, 2017 at 6:17 AM, Murtuza Zabuawala <
>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> PFA minor patch to fix the issue where node rename is not working
>>>>>> properly after 7dd9efd8
>>>>>> <https://redmine.postgresql.org/projects/pgadmin4/repository/revisions/7dd9efd811c7845d9dc985b66f8d33497f2f4bfa>
>>>>>>  commit
>>>>>> .
>>>>>> RM#2355
>>>>>>
>>>>> We should remove the existing node, and then insert at right place
>>>> instead of refreshing the parent.
>>>> Because - that will select the parent node, and not that node, and also
>>>> - it adds overhead of refreshing the whole parent node.
>>>>
>>>> Please send the patch as per our discussion.
>>>>
>>>> -- Thanks, Ashesh
>>>>
>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Murtuza Zabuawala
>>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org
>>>>>> )
>>>>>> To make changes to your subscription:
>>>>>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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-hackers] security bug (with patch-fix) -- need more HTML-escaping for working with tree-nodes

[Ashesh Vashi]

On Wed, May 10, 2017 at 1:29 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Wed, May 10, 2017 at 8:56 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Thanks.
>> Committed!
>>
>
> I agree with the change from a preventative/safety perspective, though I'm
> struggling to classify it as a security issue, given that collections are
> always named by the code and not from user input.
>
> Am I missing something?
>
True - but not the case with the server-group.
It is a collection node, still has it's own label.

-- Thanks, Ashesh

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

Re: [pgadmin-hackers] security bug (with patch-fix) -- need more HTML-escaping for working with tree-nodes

[Ashesh Vashi]

Thanks.
Committed!

--

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>

2017-05-10 1:06 GMT+05:30 Andrei Antonov <anto...@imp-m.ru>:

> good day!
>
> i fixed tiny errors (html-escaping) , but it has security effects.
>
> see file "0001-escape-label-of-node-of-tree-when-events-add-remove-.patch"
> [ https://github.com/postgres-impulsm/pgadmin4/commit/f993513d
> 148fc6dd7e0196261f847e668d5e2c6c ]
>
>
>
>
> --
> Андрей Антонов,
> инженер-программист Отдела информационных технологий и программирования,
> компания «Импульс М»
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>

[pgadmin-hackers] pgAdmin 4 commit: HTML escape the label, when setting the collection no

[Ashesh Vashi]

HTML escape the label, when setting the collection node count along
with the label of the tree-nodes.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=cbf2de6c27760669a7c7e48f6bfc47c6053309f8
Author: Andrei Antonov 

Modified Files
--
web/pgadmin/browser/templates/browser/js/node.js | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Pains and thoughts about refactoring the Tree Menu using React

[Ashesh Vashi]

On Sat, Apr 22, 2017 at 12:17 AM, Joao Pedro De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hi Hackers,
>
> After a conversation with Dave we believe that we need to provide more
> context on our pains and what we propose as a first step for implementing
> the Tree Menu using React.
>
> The pain:
>
> Here is a quick description of what we think we understand and where we
> got stuck while doing our refactor.
>
> If you look at the above image, both the NodeJS and CollectionJS classes
> are templates. Our goal was to extract those from being templates so that
> we could test them. We started with the generate_url function. The issue we
> ran into was that the generate_url function is inherited by CollectionJS
> from NodeJS but then over writes some of the functionality that it
> inherits. In order to have one function that our react component would
> delegate to, we have to consolidate these two class methods. This turned
> out to be a non-trivial refactor due to the lack of tests/documentation.
>
> Our proposal:
>
>
> This diagram represents what we believe can be our first approach to
> updating the tree. We can create a very basic tree that only does tree
> stuff (Open Node, Close Nodes) and then delegates to other adapters to
> execute all the business logic functionality (Generate URLs to get the
> node, Right Click menu, …)
>
We will loose the current extendible architecture of by creating fix number
of adapters, instead - we should generates events like right now, let the
modules/extensions decide - what to do.

There are many operations are dependents on the tree events.
e.g.
- Before open
When server node is being opened, 'beforeopen' event checks if server is
connected, or not.
If not try to connect it, otherwise it does not let it open it

- Added
Dependent modules libraries are loaded, when a particular type of node is
added.
i.e. When the first database node is added in the tree, it loads all the
schema level, and other javascript modules.

- Selected
When any of the node is added, it shows properties of the selected, change
the dashboard context (if necessary).

Current tree generates many events.
beforeload, beforeappend, added, appended, loaded, init, beforeselect,
selected, beforefocus, focused, focus, blurred, beforetoggle, beforeopen,
openned, toggled, etc.

We generate 'pgadmin-browser:tree' events on a pgBrowser.Events objects to
be used by different modules.
At the moment, 'pgadmin-browser:tree:selected' is widely used by different
modules.
i.e. SQL, dependents, dependencies, properties, Dashboard, etc.

If you want to see the complete list of events generated, you can use the
following patch.

*diff --git a/web/pgadmin/browser/static/js/datamodel.js
b/web/pgadmin/browser/static/js/datamodel.js*
*index 5b1c3a7..575c78d 100644*
*--- a/web/pgadmin/browser/static/js/datamodel.js*
*+++ b/web/pgadmin/browser/static/js/datamodel.js*
*@@ -1149,5 +1149,10 @@ function(_, pgAdmin, $, Backbone) {*

* pgBrowser.Events = _.extend({}, Backbone.Events);*

*+pgBrowser.Events.on(*
*+  'pgadmin-browser:tree', function() {*
*+console.log(arguments[0]);*
*+  });*
*+*
* return pgBrowser;*
* });*

Apart from them, we also need to understand, how the tree traversal will
work.
How would you traverse through a particular node, and expand all its parent?


> Asks:
>
>-
>
>Are there any more operation that currently are being triggered by the
>tree? If so we need to add them to the Adapter List.
>
> Please see my above comments.

>
>-
>
>Because we lack the context and knowledge of the current tree
>implementation, we need your help to extract these methods from the places
>they are currently in. We believe that a good place to start would be
>writing tests for and implementing the generation of URLs used to fetch the
>child nodes.
>
> Attached you can find an example of the JavaScript tests that we have been
> writing that can be applied to this extracted method.
>
You may want to start from here:
https://www.pgadmin.org/docs4/dev/code_snippets.html#nodeview

Every tree node is inherited from this class, you can start looking at the
DatabaseView, and DatabaseModule class.

-- Thanks, Ashesh

>
> Thanks
>
> Rob, Oliver & Joao
>
>

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Ashesh Vashi]

On Wed, Apr 26, 2017 at 9:56 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Wed, Apr 26, 2017 at 4:45 PM, Shirley Wang <sw...@pivotal.io> wrote:
>
>>
>>
>> I think the addition of icons and some copy would help:
>> [image: Screen Shot 2017-04-26 at 11.28.41 AM.png]
>>
>
> Agreed.
>
+1

--

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: [pgadmin-hackers][patch] Dependents and Dependencies in GreenPlum

[Ashesh Vashi]

On Mon, Apr 24, 2017 at 4:43 PM, Dave Page <dp...@pgadmin.org> wrote:

> Ashesh, can you review/commit this please?
>
> On Fri, Apr 21, 2017 at 8:42 PM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hi Hackers,
>>
>> We found out that when you are connected to a GreenPlum database and try
>> to get Dependents and Dependencies of an object the application was
>> returning a SQL error.
>>
>> This patch splits the SQL query used to retrieve the Dependents,
>> Dependencies, and Roles SQL file into multiple versioned files.
>> Add Unit Tests for each file.
>> Also added __init__.py files to other test directories to run the tests
>> in them.
>>
> Hi Joao & Sarah,

Why do we need to add __init__.py in the template directory?
I didn't understand the purpose of the adding __init__.py files in the
template directories.

NOTE: The headers in those files are not consistent with the other project
files.

--

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>

> Add ORDER BY into Copy Selection Feature test to ensure the results are
>> retrieved always in the same order
>> Renamed the Scenario of the xss_checks_pgadmin_debugger_test and skip it
>> for versions less than 9.1
>>
>> Thanks
>>
>> Joao & Sarah
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] [pgAdmin4][PATCH] To fix the issue with Node rename

[Ashesh Vashi]

On Mon, Apr 24, 2017 at 4:43 PM, Dave Page  wrote:

> Ashesh, can you review/commit this please? Thanks.
>
> On Mon, Apr 24, 2017 at 6:17 AM, Murtuza Zabuawala  enterprisedb.com> wrote:
>
>> Hi,
>>
>> PFA minor patch to fix the issue where node rename is not working
>> properly after 7dd9efd8
>> 
>>  commit
>> .
>> RM#2355
>>
> We should remove the existing node, and then insert at right place instead
of refreshing the parent.
Because - that will select the parent node, and not that node, and also -
it adds overhead of refreshing the whole parent node.

Please send the patch as per our discussion.

-- Thanks, Ashesh

>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

[pgadmin-hackers] pgAdmin 4 commit: Added dependency on Flask-Migrate added by previous c

[Ashesh Vashi]

Added dependency on Flask-Migrate added by previous commit:
6283ef7f5e4379d5e2202ca2919b9ea76caf57c7

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=139a10e8f9b483ede6e6578f451119bd698e1bca

Modified Files
--
requirements.txt | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

On Fri, Apr 21, 2017 at 7:59 PM, Joao Pedro De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers,
>
> We review the patch, just noticed a spelling issue so we regenerated the
> patch.
>
Thanks.
Your patch was missing README changes. :-)

Committed after adding the necessary changes.

-- Thanks,
Ashesh Vashi


>
> Thanks
> Joao & Oliver
>
> On Fri, Apr 21, 2017 at 1:21 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Joao & Oliver,
>>
>> On Fri, Apr 21, 2017 at 3:39 AM, Joao Pedro De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Hackers,
>>>
>>> @Ashesh thanks for the feedback
>>>
>>> Here is the reviewed patch with the suggestions of Ashesh.
>>>
>>> Disclaimer: We added a new patch file with the changes
>>>
>>
>> I have made some more changes to the patch.
>> - 'with app.app_context(..)' statement was not required in the
>> 'web/pgadmin/__init__.py' as we're already doing that in the do_upgrade
>> function.
>> - We also need to create other directories (i.e. sessions, storage,
>> directory containing the log-file) during the setup/running the application
>> (if not exists).
>> - Added proper check in the pgAdmin4.wsgi file (if configuration file
>> exists, or not)
>>
>> Please review it.
>>
>> -- Thanks, Ashesh
>>
>>
>

[pgadmin-hackers] pgAdmin 4 commit: [Configuration][Migration] Use 'alembic' for migratio

[Ashesh Vashi]

[Configuration][Migration] Use 'alembic' for migration of the SQLite
based configuration file from one version to another, and also allows us
to have a single path of creating the table instead of creating tables
using SQLAlchemy or hand rolled SQL

This allows us to run the migrations directly in the code, and it will
avoid the error prone version numbering.

Patched by: Sarah McAlear
Revisions: Joao Pedro De Almeida Pereira, George Gelashvili.
Reviewed by: Ashesh Vashi, Murtuza Zabuawala

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=6283ef7f5e4379d5e2202ca2919b9ea76caf57c7
Author: Sarah McAlear <smcal...@pivotal.io>

Modified Files
--
README   |  16 ++
web/migrations/alembic.ini   |  54 
web/migrations/env.py|  94 +++
web/migrations/script.py.mako|  33 +++
web/migrations/versions/09d53fca90c7_.py | 242 +
web/migrations/versions/fdc58d9bd449_.py | 128 +
web/pgAdmin4.py  |  11 -
web/pgAdmin4.wsgi|  20 ++
web/pgadmin/__init__.py  |  42 +--
web/pgadmin/setup/__init__.py|  13 +
web/pgadmin/setup/data_directory.py  |  32 +++
web/pgadmin/setup/db_upgrade.py  |  25 ++
web/pgadmin/setup/db_version.py  |  28 ++
web/pgadmin/setup/user_info.py   |  72 +
web/setup.py | 439 +--
15 files changed, 779 insertions(+), 470 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] file permission on ssl key

[Ashesh Vashi]

Hi Jeroen,

This is pgAdmin hackers list.
Please send mail to pgsql-gene...@postgresql.org mailing list for your
postgresql related queries.

--

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 Sun, Apr 23, 2017 at 11:25 PM, Jeroen Jacobs <
jeroen.jac...@headincloud.be> wrote:

> Hi,
>
> I'm getting this error when I try to configure ssl with postgres:
>
> pr 23 13:12:47 pgmaster01 pg_ctl: FATAL:  private key file
> "/etc/ssl/pgmaster01-key.pem" has group or world access
> Apr 23 13:12:47 pgmaster01 pg_ctl: DETAIL:  Permissions should be u=rw
> (0600) or less.
>
> The actual permission is:
>
> centos@pgmaster01 ~]$ ls -l /etc/ssl/pgmaster01-key.pem
> -r--r- 1 root ssl-read 3243 Apr 23 00:00 /etc/ssl/pgmaster01-key.pem
>
> postgres user is part of the ssl-read group. Thi ssl key is shared with
> other software as well, so giving exclusive access to the postgres user is
> NOT an option.
>
> I understand why postgres complains, but I'm pretty sure about what I'm
> doing here. How can I tell postgres to start anyway, even when it doesn't
> like those permissions? There should be a way to override this, I'm the
> admin here, it's up to me to decide to implement my security setup, not the
> software itself.
>
> So basically I have three options:
>
> - don't use ssl at all (not an option at all, actually)
> - create a separate copy of my ssl key file with the correct permissions
> that postgres likes (ugly workaround)
> - use another database server which allows me to configure it how I want
> it.
>
> I'm actually considering settling for the last solution, due to this crazy
> restriction you put in place...
>
>
> Regards,
>
> Jeroen.
>

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

Hi Joao & Oliver,

On Fri, Apr 21, 2017 at 3:39 AM, Joao Pedro De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers,
>
> @Ashesh thanks for the feedback
>
> Here is the reviewed patch with the suggestions of Ashesh.
>
> Disclaimer: We added a new patch file with the changes
>

I have made some more changes to the patch.
- 'with app.app_context(..)' statement was not required in the
'web/pgadmin/__init__.py' as we're already doing that in the do_upgrade
function.
- We also need to create other directories (i.e. sessions, storage,
directory containing the log-file) during the setup/running the application
(if not exists).
- Added proper check in the pgAdmin4.wsgi file (if configuration file
exists, or not)

Please review it.

-- Thanks, Ashesh


alembic_migration_system.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

On Thu, Apr 20, 2017 at 8:15 PM, Joao Pedro De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Ashesh,
>
> Did you had time to review this patch?
>
Yes - I did.

Please my review comments:
Everytime I start pgAdmin 4, I am getting now the following message:
"pgAdmin 4 - Application Initialisation"

Can we avoid that message?
We are not providing any information during upgrade process.
i.e. older version was so, and so, it will be upgraded to so, and so.

It helps sometimes to while debugging the application.

Rest looks fine to me.

-- Thanks, Ashesh

>
> Thanks
> Joao & Oliver
>
> On Wed, Apr 12, 2017 at 9:52 AM, Sarah McAlear <smcal...@pivotal.io>
> wrote:
>
>> Great, thank you so much!
>>
>> On Wed, Apr 12, 2017 at 9:41 AM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>>
>>> On Wed, Apr 12, 2017 at 7:07 PM, Sarah McAlear <smcal...@pivotal.io>
>>> wrote:
>>>
>>>> Hi Hackers!
>>>>
>>> Hi Sarah,
>>>
>>>>
>>>> Is there an update on this?
>>>>
>>> We will look in to it end of this week.
>>> I was not rushing to it, because - Dave was preparing for the 1.4
>>> release.
>>>
>>> -- Thanks, Ashesh
>>>
>>>>
>>>> Thanks,
>>>> Sarah & Joao
>>>>
>>>> On Fri, Apr 7, 2017 at 10:27 AM, Sarah McAlear <smcal...@pivotal.io>
>>>> wrote:
>>>>
>>>>> Hi Ashesh!
>>>>>
>>>>> Good catch. Looks like there was an override of the input function
>>>>> that didn't get moved to the new file, causing the input with the @ to
>>>>> fail. We also added headers to the files that were missing them. This new
>>>>> patch should work.
>>>>>
>>>>> Thanks!
>>>>> Joao & Sarah
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 3, 2017 at 8:41 AM, Ashesh Vashi <
>>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>>
>>>>>> On Mon, Apr 3, 2017 at 12:09 PM, Ashesh Vashi <
>>>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Hi Jaoao, Sarah,
>>>>>>>
>>>>>>> I've tried to run on fresh machine, it failed with the below error:
>>>>>>>
>>>>>> And - I have noticed - the headers are missing in new files.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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>
>>>>>>
>>>>>>>
>>>>>>> *$ python setup.py*
>>>>>>> *NOTE: Configuring authentication for SERVER mode.*
>>>>>>>
>>>>>>> *Enter the email address and password to use for the initial pgAdmin
>>>>>>> user account:*
>>>>>>>
>>>>>>> *Email address: ashesh.va...@enterprisedb.com
>>>>>>> <ashesh.va...@enterprisedb.com>*
>>>>>>> *Traceback (most recent call last):*
>>>>>>> *  File "setup.py", line 52, in *
>>>>>>> *db_upgrade(app)*
>>>>>>> *  File
>>>>>>> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/db_upgrade.py",
>>>>>>> line 25, in db_upgrade*
>>>>>>> *flask_migrate.upgrade(migration_folder)*
>>>>>>> *  File
>>>>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/flask_migrate/__init__.py",
>>>>>>> line 244, in upgrade*
>>>>>>> *command.upgrade(config, revision, sql=sql, tag=tag)*
>>>>>>> *  File
>>>>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/command.py",
>>>>>>> line 254, in upgrade*
>>>>>>> *script.run_env()*
>>>>>>> *  File
>>>>>>> "/Users/asheshvashi/Developments/WorkPl

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

On Wed, Apr 12, 2017 at 7:07 PM, Sarah McAlear <smcal...@pivotal.io> wrote:

> Hi Hackers!
>
Hi Sarah,

>
> Is there an update on this?
>
We will look in to it end of this week.
I was not rushing to it, because - Dave was preparing for the 1.4 release.

-- Thanks, Ashesh

>
> Thanks,
> Sarah & Joao
>
> On Fri, Apr 7, 2017 at 10:27 AM, Sarah McAlear <smcal...@pivotal.io>
> wrote:
>
>> Hi Ashesh!
>>
>> Good catch. Looks like there was an override of the input function that
>> didn't get moved to the new file, causing the input with the @ to fail. We
>> also added headers to the files that were missing them. This new patch
>> should work.
>>
>> Thanks!
>> Joao & Sarah
>>
>>
>>
>> On Mon, Apr 3, 2017 at 8:41 AM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> On Mon, Apr 3, 2017 at 12:09 PM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
>>>> Hi Jaoao, Sarah,
>>>>
>>>> I've tried to run on fresh machine, it failed with the below error:
>>>>
>>> And - I have noticed - the headers are missing in new files.
>>>
>>> --
>>>
>>> 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>
>>>
>>>>
>>>> *$ python setup.py*
>>>> *NOTE: Configuring authentication for SERVER mode.*
>>>>
>>>> *Enter the email address and password to use for the initial pgAdmin
>>>> user account:*
>>>>
>>>> *Email address: ashesh.va...@enterprisedb.com
>>>> <ashesh.va...@enterprisedb.com>*
>>>> *Traceback (most recent call last):*
>>>> *  File "setup.py", line 52, in *
>>>> *db_upgrade(app)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/db_upgrade.py",
>>>> line 25, in db_upgrade*
>>>> *flask_migrate.upgrade(migration_folder)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/flask_migrate/__init__.py",
>>>> line 244, in upgrade*
>>>> *command.upgrade(config, revision, sql=sql, tag=tag)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/command.py",
>>>> line 254, in upgrade*
>>>> *script.run_env()*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/script/base.py",
>>>> line 416, in run_env*
>>>> *util.load_python_file(self.dir, 'env.py')*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/util/pyfiles.py",
>>>> line 93, in load_python_file*
>>>> *module = load_module_py(module_id, path)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/util/compat.py",
>>>> line 75, in load_module_py*
>>>> *mod = imp.load_source(module_id, path, fp)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/../../migrations/env.py",
>>>> line 85, in *
>>>> *run_migrations_online()*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/../../migrations/env.py",
>>>> line 78, in run_migrations_online*
>>>> *context.run_migrations()*
>>>> *  File "", line 8, in run_migrations*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/runtime/environment.py",
>>>> line 817, in run_migrations*
>>>> *self.get_context().run_migrations(**kw)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/runtime/migration.py",
>>>> line 323, in run_migrations*
>>>> *step.migration_fn(**kw)*
>>>> *  File
>>>> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/migrations/versions/fdc58d9bd449_.py",
>>>

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Fix the issue in browser tree

[Ashesh Vashi]

Murtuza - please fix it asap.

--

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 Fri, Apr 7, 2017 at 1:59 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hmm, I think this might have broken adding of new nodes in some cases. I
> just added two new tables (right-clicking the public schema), and had to
> refresh the tables node before they showed up.
>
> On Fri, Apr 7, 2017 at 4:29 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Thanks - committed!
>>
>> --
>>
>> 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 Thu, Apr 6, 2017 at 11:21 AM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hello,
>>>
>>> PFA patch to fix the issue in browser tree when adding new node if
>>> parent collection node is not loaded.
>>> *Fixes:* RM#2321
>>>
>>> Steps:
>>> 1) Open pgAdmin4.
>>> 2) Do not expand server-group node.
>>> 3) Right click on server-group collection node and add server, now click
>>> on save button
>>> (This issue is reproducible on any collection node which is not loaded)
>>> 4) You will see that only newly added node is displayed in browser tree
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> --
>>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>>
>>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Fix the issue in browser tree

[Ashesh Vashi]

Thanks - committed!

--

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 Thu, Apr 6, 2017 at 11:21 AM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hello,
>
> PFA patch to fix the issue in browser tree when adding new node if parent
> collection node is not loaded.
> *Fixes:* RM#2321
>
> Steps:
> 1) Open pgAdmin4.
> 2) Do not expand server-group node.
> 3) Right click on server-group collection node and add server, now click
> on save button
> (This issue is reproducible on any collection node which is not loaded)
> 4) You will see that only newly added node is displayed in browser tree
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>

[pgadmin-hackers] pgAdmin 4 commit: Fixes #2321 - [Browser Tree] Shows only the newly cre

[Ashesh Vashi]

Fixes #2321 - [Browser Tree] Shows only the newly created node (not, all
other child node) of a parent node, when it has not been already loaded.

In order to resolve the issue - we will open the parent, and select the
created node, instead of adding it to parent node.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=3dba7d8303f709bc42007bc798a8673a120b10e3
Author: Murtuza Zabuawala 

Modified Files
--
web/pgadmin/browser/templates/browser/js/browser.js | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Error running restore/backup etc utilities in WSGI mode

[Ashesh Vashi]

On Mon, Apr 3, 2017 at 6:57 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com>
wrote:

> On Mon, Apr 3, 2017 at 6:33 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Thanks - committed!
>>
> Committed a lot better solution.
> User can set '$DIR' in the bin_path.
>
> We needed to check existence of the '__file__' attribute in the '__main__'
> module, when running as a WSGI application.
>
Thanks - Murtuza for pointing the typo.
Check should have been 'is not None', instead of 'is None'.

Sorry - looks like, I need a break! :-(

--

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>

>
> --
>
> 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>
>
>>
>> --
>>
>> 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 Mon, Apr 3, 2017 at 6:23 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> PFA minor patch to fix the issue where user gets error when try to run
>>> backup/restore etc in pgAdmin4 WSGI mode.
>>>
>>> Error in Apache log:
>>>
>>> [Mon Apr 03 05:22:26.641789 2017] [wsgi:error] [pid 72351:tid
>>> 140303938864896] [remote ::1:28430] File 
>>> "/opt/web/pgadmin/utils/driver/psycopg2/__init__.py",
>>> line 1664, in utility
>>> [Mon Apr 03 05:22:26.641818 2017] [wsgi:error] [pid 72351:tid
>>> 140303938864896] [remote ::1:28430] return 
>>> self.server_cls.utility(operation,
>>> self.sversion)
>>> [Mon Apr 03 05:22:26.641883 2017] [wsgi:error] [pid 72351:tid
>>> 140303938864896] [remote ::1:28430] File 
>>> "/opt/web/pgadmin/browser/server_groups/servers/types.py",
>>> line 120, in utility
>>> [Mon Apr 03 05:22:26.641921 2017] [wsgi:error] [pid 72351:tid
>>> 140303938864896] [remote ::1:28430] bin_path =
>>> self.utility_path.get().replace("$DIR", os.path.dirname(sys.modules['_
>>> _main__'].__file__))
>>> [Mon Apr 03 05:22:26.641958 2017] [wsgi:error] [pid 72351:tid
>>> 140303938864896] [remote ::1:28430] AttributeError: 'module' object has no
>>> attribute '__file__'
>>>
>>>
>>> In WSGI, we get sys.modules['__main__'] as built-in object.
>>>
>>>
>>> '__main__': ,
>>> 'pgadmin.browser.server_groups.servers.databases.schemas.tables.rules':
>>> >> 'pgadmin.browser.server_groups.servers.databases.schemas.tables.rules'
>>> from '/opt/PEM/server/share/web/pgadmin/browser/server_groups/ser
>>> vers/databases/schemas/tables/rules/__init__.py'>,
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> --
>>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>>
>>>
>>
>

[pgadmin-hackers] pgAdmin 4 commit: Resolved a typo in the previous commit.

[Ashesh Vashi]

Resolved a typo in the previous commit.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=4d55e8abe8fbb90f69e4984f71150fbd04a60695

Modified Files
--
web/pgadmin/browser/server_groups/servers/types.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Error running restore/backup etc utilities in WSGI mode

[Ashesh Vashi]

On Mon, Apr 3, 2017 at 6:33 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com>
wrote:

> Thanks - committed!
>
Committed a lot better solution.
User can set '$DIR' in the bin_path.

We needed to check existence of the '__file__' attribute in the '__main__'
module, when running as a WSGI application.

--

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>

>
> --
>
> 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 Mon, Apr 3, 2017 at 6:23 PM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi,
>>
>> PFA minor patch to fix the issue where user gets error when try to run
>> backup/restore etc in pgAdmin4 WSGI mode.
>>
>> Error in Apache log:
>>
>> [Mon Apr 03 05:22:26.641789 2017] [wsgi:error] [pid 72351:tid
>> 140303938864896] [remote ::1:28430] File 
>> "/opt/web/pgadmin/utils/driver/psycopg2/__init__.py",
>> line 1664, in utility
>> [Mon Apr 03 05:22:26.641818 2017] [wsgi:error] [pid 72351:tid
>> 140303938864896] [remote ::1:28430] return self.server_cls.utility(operation,
>> self.sversion)
>> [Mon Apr 03 05:22:26.641883 2017] [wsgi:error] [pid 72351:tid
>> 140303938864896] [remote ::1:28430] File 
>> "/opt/web/pgadmin/browser/server_groups/servers/types.py",
>> line 120, in utility
>> [Mon Apr 03 05:22:26.641921 2017] [wsgi:error] [pid 72351:tid
>> 140303938864896] [remote ::1:28430] bin_path =
>> self.utility_path.get().replace("$DIR", os.path.dirname(sys.modules['_
>> _main__'].__file__))
>> [Mon Apr 03 05:22:26.641958 2017] [wsgi:error] [pid 72351:tid
>> 140303938864896] [remote ::1:28430] AttributeError: 'module' object has no
>> attribute '__file__'
>>
>>
>> In WSGI, we get sys.modules['__main__'] as built-in object.
>>
>>
>> '__main__': ,
>> 'pgadmin.browser.server_groups.servers.databases.schemas.tables.rules':
>> > 'pgadmin.browser.server_groups.servers.databases.schemas.tables.rules'
>> from '/opt/PEM/server/share/web/pgadmin/browser/server_groups/ser
>> vers/databases/schemas/tables/rules/__init__.py'>,
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>

[pgadmin-hackers] pgAdmin 4 commit: As per Murtuza, we will have the '__module__', when r

[Ashesh Vashi]

As per Murtuza, we will have the '__module__', when running as a WSGI
application, but - it will not have the '__file__' attribute.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=02a3919b0627dc27c4deecc38b17f6e75acb0051

Modified Files
--
web/pgadmin/browser/server_groups/servers/types.py | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: When running pgAdmin as a WSGI application, we will n

[Ashesh Vashi]

When running pgAdmin as a WSGI application, we will not be able to find
the '__main__' module under 'sys.modules'.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=b756407c3cb3e4afd40591b65902c390eb2b723f

Modified Files
--
web/pgadmin/browser/server_groups/servers/types.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Error running restore/backup etc utilities in WSGI mode

[Ashesh Vashi]

Thanks - committed!

--

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 Mon, Apr 3, 2017 at 6:23 PM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hi,
>
> PFA minor patch to fix the issue where user gets error when try to run
> backup/restore etc in pgAdmin4 WSGI mode.
>
> Error in Apache log:
>
> [Mon Apr 03 05:22:26.641789 2017] [wsgi:error] [pid 72351:tid
> 140303938864896] [remote ::1:28430] File 
> "/opt/web/pgadmin/utils/driver/psycopg2/__init__.py",
> line 1664, in utility
> [Mon Apr 03 05:22:26.641818 2017] [wsgi:error] [pid 72351:tid
> 140303938864896] [remote ::1:28430] return self.server_cls.utility(operation,
> self.sversion)
> [Mon Apr 03 05:22:26.641883 2017] [wsgi:error] [pid 72351:tid
> 140303938864896] [remote ::1:28430] File "/opt/web/pgadmin/browser/
> server_groups/servers/types.py", line 120, in utility
> [Mon Apr 03 05:22:26.641921 2017] [wsgi:error] [pid 72351:tid
> 140303938864896] [remote ::1:28430] bin_path = 
> self.utility_path.get().replace("$DIR",
> os.path.dirname(sys.modules['__main__'].__file__))
> [Mon Apr 03 05:22:26.641958 2017] [wsgi:error] [pid 72351:tid
> 140303938864896] [remote ::1:28430] AttributeError: 'module' object has no
> attribute '__file__'
>
>
> In WSGI, we get sys.modules['__main__'] as built-in object.
>
>
> '__main__': ,
> 'pgadmin.browser.server_groups.servers.databases.schemas.tables.rules':
>  from '/opt/PEM/server/share/web/pgadmin/browser/server_groups/
> servers/databases/schemas/tables/rules/__init__.py'>,
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>

[pgadmin-hackers] pgAdmin 4 commit: Replace the '$DIR' only when found in the binary dire

[Ashesh Vashi]

Replace the '$DIR' only when found in the binary directory string.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=74655e60a04d1fcccfda1be03ab4e602428748b2
Author: Murtuza Zabuawala 

Modified Files
--
web/pgadmin/browser/server_groups/servers/types.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

On Mon, Apr 3, 2017 at 12:09 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com
> wrote:

> Hi Jaoao, Sarah,
>
> I've tried to run on fresh machine, it failed with the below error:
>
And - I have noticed - the headers are missing in new files.

--

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>

>
> *$ python setup.py*
> *NOTE: Configuring authentication for SERVER mode.*
>
> *Enter the email address and password to use for the initial pgAdmin user
> account:*
>
> *Email address: ashesh.va...@enterprisedb.com
> <ashesh.va...@enterprisedb.com>*
> *Traceback (most recent call last):*
> *  File "setup.py", line 52, in *
> *db_upgrade(app)*
> *  File
> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/db_upgrade.py",
> line 25, in db_upgrade*
> *flask_migrate.upgrade(migration_folder)*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/flask_migrate/__init__.py",
> line 244, in upgrade*
> *command.upgrade(config, revision, sql=sql, tag=tag)*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/command.py",
> line 254, in upgrade*
> *script.run_env()*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/script/base.py",
> line 416, in run_env*
> *util.load_python_file(self.dir, 'env.py')*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/util/pyfiles.py",
> line 93, in load_python_file*
> *module = load_module_py(module_id, path)*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/util/compat.py",
> line 75, in load_module_py*
> *mod = imp.load_source(module_id, path, fp)*
> *  File
> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/../../migrations/env.py",
> line 85, in *
> *run_migrations_online()*
> *  File
> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/../../migrations/env.py",
> line 78, in run_migrations_online*
> *context.run_migrations()*
> *  File "", line 8, in run_migrations*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/runtime/environment.py",
> line 817, in run_migrations*
> *self.get_context().run_migrations(**kw)*
> *  File
> "/Users/asheshvashi/Developments/WorkPlace/pgAdmin4/lib/python2.7/site-packages/alembic/runtime/migration.py",
> line 323, in run_migrations*
> *step.migration_fn(**kw)*
> *  File
> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/migrations/versions/fdc58d9bd449_.py",
> line 84, in upgrade*
> *email, password = user_info()*
> *  File
> "/Users/asheshvashi/Developments/Projects/pgAdmin4/web/pgadmin/setup/user_info.py",
> line 50, in user_info*
> *email = input("Email address: ")*
> *  File "", line 1*
> *ashesh.va...@enterprisedb.com <ashesh.va...@enterprisedb.com>*
> *^*
> *SyntaxError: invalid syntax*
>
>
> --
>
> 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 Fri, Mar 31, 2017 at 8:17 PM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi,
>>
>> PFA minor add-on patch for README.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Fri, Mar 31, 2017 at 8:04 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi Ashesh,
>>>
>>> Patch looks good to me.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> On Fri, Mar 31, 2017 at 1:10 PM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
>>>> Hi Joao & Sarah,
>>>>
>>>> I have asked Murtuza to review the patch today.
>>>> He will update me by EOD.
>>>>
>>>> If all goes well, I will commit the patch.
>>>>
>

[pgadmin-hackers] pgAdmin 4 commit: Fixes #2304, #2145 - Resolve the issue for restoring

[Ashesh Vashi]

Fixes #2304, #2145 - Resolve the issue for restoring the table from the backup.

Earlier - implementation was generating the backup code like as below:
XXX/pg_restore.exe --host "x.x.x.x" --port "" --username "osboxes" 
--no-password --dbname "test" --data-only --verbose --table "tt.test2" 
"XXX-FILE.bak"

It should have been:
XXX/pg_restore.exe --host "x.x.x.x" --port "" --username "osboxes" 
--no-password --dbname "test" --data-only --verbose --schema "tt" --table 
"test2" "XXX-FILE.bak"

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=8005b0529227ca8fbbb1252475c5a4ec9fcc5330
Author: Maxim Zakharov 

Modified Files
--
web/pgadmin/tools/restore/__init__.py   | 10 +-
.../tools/restore/templates/restore/js/restore.js   | 17 +++--
2 files changed, 16 insertions(+), 11 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers][patch] Move to Alembic migration system

[Ashesh Vashi]

Hi Joao & Sarah,

I have asked Murtuza to review the patch today.
He will update me by EOD.

If all goes well, I will commit the patch.

--

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 Thu, Mar 30, 2017 at 8:36 PM, Joao Pedro De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Dave and Ashesh,
>
> Do you still need us to provide more information about this patch or is it
> ready to be merged?
>
> Thanks
> Joao
>
> On Thu, Mar 23, 2017 at 12:00 PM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello Hackers,
>>
>> We found out a issue using Python 3 related to importing modules that we
>> corrected in the patch that is now attached.
>>
>> Also we would like to know the status of this.
>>
>> Thanks
>> Joao & Sarah
>>
>> On Fri, Mar 17, 2017 at 10:32 AM, Sarah McAlear <smcal...@pivotal.io>
>> wrote:
>>
>>> Hi!
>>>
>>> We realized that this change was causing the tests to fail because the
>>> folder for the sqlite databases was not being created. We also updated the
>>> files to contain the missing headers.
>>>
>>> Thanks!
>>> Joao & Sarah
>>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 9:31 AM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> Ashesh, can you review/commit this please? One thing I notice on a
>>>> quick look through is that the file headers are missing everywhere.
>>>> They should be present in all source files, except where they would
>>>> bloat the data transfer from client to server.
>>>>
>>>> On Wed, Mar 15, 2017 at 8:09 PM, Sarah McAlear <smcal...@pivotal.io>
>>>> wrote:
>>>> > Hi Hackers!
>>>> >
>>>> > It looks like our previous patch messed up some logging. Please use
>>>> this one
>>>> > instead.
>>>> >
>>>> > Thanks,
>>>> > Joao & Sarah
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Mar 15, 2017 at 2:46 PM, Sarah McAlear <smcal...@pivotal.io>
>>>> wrote:
>>>> >>
>>>> >> Hi Hackers!
>>>> >>
>>>> >> Here's a patch to move to current db migration system to use Alembic.
>>>> >> Instructions to create new migrations are in the README.
>>>> >>
>>>> >> Thanks!
>>>> >> Joao & Sarah
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org
>>>> )
>>>> > To make changes to your subscription:
>>>> > http://www.postgresql.org/mailpref/pgadmin-hackers
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Dave Page
>>>> Blog: http://pgsnake.blogspot.com
>>>> Twitter: @pgsnake
>>>>
>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>
>>>
>>
>

Re: [pgadmin-hackers][patch] Raise InternalServerError while retrieving table DDL

[Ashesh Vashi]

On Fri, Mar 24, 2017 at 7:19 PM, Atira Odhner <aodh...@pivotal.io> wrote:

> When we were working on the DDL story, we found that some methods were
> returning the internal_server_error json, but the code that called those
> methods was not expecting that type of object. So, instead of returning
> that json to the user, the code would try to treat the json as a different
> type of object which often resulted in a different internal server error
> than the one that was intended.
>
> We decided to raise the error instead so that there would be no risk of
> the code interacting with the error object in an unexpected way, since it
> will raise up and skip over that code. Then, we added a handler for the
> error which returns the same type of internal_server_error which was
> intended originally. This ensures that the user sees the proper error
> messages.
>
I understand your concern about the Exception object.
But - what was the need to change the existing code, where it was working.

i.e.
*@@ -783,7 +785,7 @@ class TableView(PGChildNodeView, DataTypeReader,
VacuumSettings):*
* 25  status, result = self.conn.execute_dict(sql)*
* 26 •*
* 27  if not status:*
* 28 -return internal_server_error(errormsg=result)*
* 29 +raise InternalServerError(result)*
* 30 •*
* 31  for fk in result['rows']:*
* 32 •*

In above code (and, similar), why do we need that change at all?

-- Thanks, Ashesh

>
> Tira & Joao
>
> On Fri, Mar 24, 2017 at 9:15 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Fri, Mar 24, 2017 at 5:07 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> Ashesh, can you review/commit this please?
>>>
>>> On Thu, Mar 23, 2017 at 3:49 PM, Joao Pedro De Almeida Pereira
>>> <jdealmeidapere...@pivotal.io> wrote:
>>> > Hi Hackers,
>>> >
>>> > While doing the DDL patch we found out that the code was not working
>>> > properly when errors happened during SQL execution:
>>> >
>>> > One example of this can be found in the file:
>>> >
>>> > web/pgadmin/browser/server_groups/servers/databases/schemas/
>>> tables/__init__.py
>>> >
>>> > The function '_formatter' that returns internal_server_error when an
>>> error
>>> > occur executing SQL
>>> > Nevertheless the 'sql' function uses the output of '_formatter' during
>>> the
>>> > execution without checking it.
>>> >
>>> > To solve this issue we raise an InternalServerError exception that we
>>> catch
>>> > in the 'sql' function instead of returning an error message.
>>>
>> Hi Joa & Sarah,
>>
>> I am not against putting the try..except block.
>>
>> We're already have out own version of 'internal_server_error', which will
>> return value in JSON format.
>> But - I did not understand the reason to change them with
>> 'werkzeug.exceptions.InternalServerError'.
>>
>> Can you please elaborate about that change?
>>
>>
>> -- Thanks, Ashesh
>>
>> >
>>> >
>>> > Thanks
>>> > Joao & Sarah
>>> >
>>> >
>>> > --
>>> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>>> > To make changes to your subscription:
>>> > http://www.postgresql.org/mailpref/pgadmin-hackers
>>> >
>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>

Re: [pgadmin-hackers][patch] Raise InternalServerError while retrieving table DDL

[Ashesh Vashi]

On Fri, Mar 24, 2017 at 5:07 PM, Dave Page  wrote:

> Ashesh, can you review/commit this please?
>
> On Thu, Mar 23, 2017 at 3:49 PM, Joao Pedro De Almeida Pereira
>  wrote:
> > Hi Hackers,
> >
> > While doing the DDL patch we found out that the code was not working
> > properly when errors happened during SQL execution:
> >
> > One example of this can be found in the file:
> >
> > web/pgadmin/browser/server_groups/servers/databases/
> schemas/tables/__init__.py
> >
> > The function '_formatter' that returns internal_server_error when an
> error
> > occur executing SQL
> > Nevertheless the 'sql' function uses the output of '_formatter' during
> the
> > execution without checking it.
> >
> > To solve this issue we raise an InternalServerError exception that we
> catch
> > in the 'sql' function instead of returning an error message.
>
Hi Joa & Sarah,

I am not against putting the try..except block.

We're already have out own version of 'internal_server_error', which will
return value in JSON format.
But - I did not understand the reason to change them with
'werkzeug.exceptions.InternalServerError'.

Can you please elaborate about that change?


-- Thanks, Ashesh

>
> >
> > Thanks
> > Joao & Sarah
> >
> >
> > --
> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgadmin-hackers
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] Re-vamping the history tab

[Ashesh Vashi]

On Thu, Mar 23, 2017 at 8:23 PM, Dave Page  wrote:

> On Thu, Mar 23, 2017 at 1:51 PM, Atira Odhner  wrote:
> >
> > We will use jquery to make ajax calls that fetch the history data, but
> > actually rendering that data and managing the data once it has been
> fetched
> > will be handled with React.
> >
> > Backbone is not as powerful as React, and does not provide the ease of
> > ensuring a consistent state:
> > for example, which tree node is expanded and which context menu applies
> to
> > each node.
> >
> > Granted, the history tab has less state to manage than the tree. It still
> > has some:
> > which row is highlighted in the left panel and which data is displayed in
> > the right.
> >
> > That's part of why I think the history tab is a good place to start with
> > React. it is a simple demonstration of the way React will drop in.
>
> I think it's a poor example; firstly because those of us that will
> have to review the code will have zero experience at that time, and
> secondly because it doesn't really give us a good basis for
> comparison.
>
> A rewrite of a treeview node or two and something like the Grant
> Wizard would likely be far more convincing, as they would allow us to
> make an apples to apples comparison, and really understand the
> practical differences between the two technologies.
>
> I'd also want a committed plan to migrate - I do not want to end up in
> a situation where we have a mish-mash of backbone and react for any
> real period of time.
>
First impression of react from blogs, sites are looking promising.
And, I am not against changing it.

But - I agree with Dave.
Using the new technology with new feature will not give us the metrics for
comparison.

>
> > Backbone tends to leak memory over time unless you are very careful about
> > unbinding events when re-rendering. So users switching between various
> items
> > in history tab may have a degraded experience over time if we use
> backbone.
>
Agree - we need to be extra careful using the Backbone, when attaching the
events.
Specially - when we attach them from the 'render' function.
(Also - there are many corner cases, when we need(ed) to be careful.)

We tried that the same with the current implementation.
I won't claim - it's completely leak proof.
But - we always improved over the period of time.

> >
> > Using react will make it easier to avoid situations like the one that has
> > developed with the server tree bug.
>
Hmm.. I do not agree here.
Yes - there is a bug, and we need to fix it.
How does it make it easier to

>
> > Pgadmin4 is a heavily client-side application, and its Javascript code
> needs
> > to be treated as a first class citizen. The same principles of needing
> to be
> > highly componentized, easily understood by future developers, and readily
> > changeable should be applied to the front end code.
>
True, we could have done better.

>
> For sure - we also need to be mindful of bloat and having
> half-implemented changes (which is really is my biggest issue here)
> that we end up having to maintain for years to come. Worst case
> scenario for me would be that your team starts a migration project,
> whilst my team builds new features on that work, then for whatever
> reason, the Pivotal team stops the work halfway through, leaving us
> with a mess of code that we cannot easily fix without finding a bunch
> of resources.
>
+1

>
> I will stress that I have no reason to expect Pivotal to do that, but
> I have been burnt in that way by other (now defunct) Postgres
> companies and recovery took years.
>
Agree with Dave here.
Backbone is tightly bound with the application at the moment, and replacing
it will need lot of thoughts, consideration, planning, and commitment.

> Here are some resources on react for the interested:
> >
> > React vs Backbone:
> > http://www.code-experience.com/react-js-vs-traditional-
> mvc-backbone-ember-angular/
> >
> > React vs Angular:
> > https://medium.com/@paramsingh_66174/angularjs-vs-reactjs-e651a194dfcb#.
> oopgbfq3z
> >
> > Another quick take on why react:
> > https://www.syncano.io/blog/reactjs-reasons-why-part-1/
>
> It certains sounds like it would be a good move from a purely
> technical perspective.

+1

-- Thanks, Ashesh

I absolutely need to hear opinions from the EDB
> team though (CC'd).


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

Re: [pgadmin-hackers] Feature test regression failures

[Ashesh Vashi]

On Wed, Mar 22, 2017 at 7:23 PM, Atira Odhner <aodh...@pivotal.io> wrote:

>  First - let me try to explain the problem with the failure in the
>> feature test.
>> We do not load all the javascript libraries, when starting the pgAdmin 4
>> (i.e. the loading the browser/index.html).
>> But - load them only when first tree-item of certain type is added.
>> e.g. We load the javascript module of 'table', 'index', etc only after
>> first tree item of database is added in the tree.
>
>
> I've seen this bug opening the tree by hand, so it is not merely a matter
> of opening tree items as quickly as a machine. There are two different code
> paths for loading the tree state --- the way the initial load happens upon
> expand and the call that is made when the user clicks 'Refresh...' in the
> context menu. Maybe a good approach to starting to fix this bug would be to
> have only one code path for loading tree state.
>
What do you mean by that?

> I don't think this has to do with loading the javascript modules.
>
It is - we've personally experienced the same in early phase of the
development, when the spinner control was not implemented.
We have seen that - when we expand the tree node, it does reloads the
server-groups under the server-group node, just because of the same reason.

>
>
>> But - as I said earlier, it represents the data for the tree-item (not
>> the item itself).
>> Hence -  it should be 'itemData', and not 'item'.
>>
>
> 'itemData' and 'item' are both fine with me.
>
>
>> We've already used 'd' to represent the data, 'i' for item, 't' for tree
>> at all other places in pgAdmin 4.
>> So - it is consistent across the application.
>
>
> Consistency is great, but in this case, aiming for consistency is
> hindering the legibility of the application code. At some point, we should
> go through the whole application and change all the 'i' to 'item', 'd' to
> data', etc. Until then, I think it is worthwhile to sacrifice consistency
> in exchange for adding meaning and clarity to the code that is being
> updated.
>
To be honest, not in that case.
As the current choice of the alphabet tells enough about the meaning of the
code.

We're deviating from the actual point at the moment, so - let's concentrate
on that first.
I would change it to itemData.

-- Thanks, Ashesh

>
> Tira & Joao
>
> On Wed, Mar 22, 2017 at 2:20 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>>
>>
>> --
>>
>> 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 Tue, Mar 21, 2017 at 9:20 PM, Atira Odhner <aodh...@pivotal.io> wrote:
>>
>>> Here is a new patchset that instead hides the spinner when the acitree
>>> has been initialized. On average, the spinner seems to disappear about 2
>>> seconds sooner, and I haven't seen flakiness with these changes yet.
>>>
>>> Tira & Joao
>>>
>>> On Mon, Mar 20, 2017 at 4:17 PM, Atira Odhner <aodh...@pivotal.io>
>>> wrote:
>>>
>>>> Note that this patch makes the problem of the tree not having loaded
>>>> worse, because it only waits for js modules to load rather than arbitrarily
>>>> waiting 900ms.
>>>>
>>> The patch was never intended to remove the spinner earlier.
>> Idea was: the spinner should be hidden only after all dependent
>> javascript modules are loaded.
>>
>> I agree about using arbitrary wait was never a good option for sure.
>> Though - I still see the flaw in my approach.
>> If the dependent script has error, it wont get loaded, and can make the
>> things worse by not hiding the spinner at all.
>>
>> I liked the idea behind your first patch about using the tree events to
>> hide the spinner.
>> Though - I see scope of improvement in it.
>>
>> On Mon, Mar 20, 2017 at 3:17 PM, Atira Odhner <aodh...@pivotal.io> wrote:
>>>>
>>>>> Hi Ashesh,
>>>>>
>>>>> *Regarding your second patch:*
>>>>>
>>>>> It looks like your second patch addresses module loading. This is an
>>>>> improvement over the previous hard timeout, but won’t do anything for the
>>>>> tree issues. The module loading code can also be simplified; we’ve 
>>>>> attached
>>>>> a patchset that is tidier, tests the behavior, and speeds up the polling.
>>>>>
>&

Re: [pgadmin-hackers] Feature test regression failures

[Ashesh Vashi]

--

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 Tue, Mar 21, 2017 at 9:20 PM, Atira Odhner <aodh...@pivotal.io> wrote:

> Here is a new patchset that instead hides the spinner when the acitree has
> been initialized. On average, the spinner seems to disappear about 2
> seconds sooner, and I haven't seen flakiness with these changes yet.
>
> Tira & Joao
>
> On Mon, Mar 20, 2017 at 4:17 PM, Atira Odhner <aodh...@pivotal.io> wrote:
>
>> Note that this patch makes the problem of the tree not having loaded
>> worse, because it only waits for js modules to load rather than arbitrarily
>> waiting 900ms.
>>
> The patch was never intended to remove the spinner earlier.
Idea was: the spinner should be hidden only after all dependent javascript
modules are loaded.

I agree about using arbitrary wait was never a good option for sure.
Though - I still see the flaw in my approach.
If the dependent script has error, it wont get loaded, and can make the
things worse by not hiding the spinner at all.

I liked the idea behind your first patch about using the tree events to
hide the spinner.
Though - I see scope of improvement in it.

On Mon, Mar 20, 2017 at 3:17 PM, Atira Odhner <aodh...@pivotal.io> wrote:
>>
>>> Hi Ashesh,
>>>
>>> *Regarding your second patch:*
>>>
>>> It looks like your second patch addresses module loading. This is an
>>> improvement over the previous hard timeout, but won’t do anything for the
>>> tree issues. The module loading code can also be simplified; we’ve attached
>>> a patchset that is tidier, tests the behavior, and speeds up the polling.
>>>
>>> Ashesh, can you explain why you are setting the text on the spinner
>>> after hiding it, or why you are hiding it rather than removing it?
>>>
>> First - let me try to explain the problem with the failure in the feature
test.
We do not load all the javascript libraries, when starting the pgAdmin 4
(i.e. the loading the browser/index.html).
But - load them only when first tree-item of certain type is added.
e.g. We load the javascript module of 'table', 'index', etc only after
first tree item of database is added in the tree.

Now - when we run the feature tests, it expands all the nodes one by one
very quickly.
And, that makes the thing worse, as the javascript module for 'table' is
still not loaded in the browser, definitely - not immediately after the
first 'database' item is added, it always takes some time to load the
module, and takes few fraction of seconds/milliseconds.

Now - the intention was show the spinner, when the dependent javascript
modules gets loaded.
Hence - we did not remove the spinner, but - instead only hide it.

And, changed the text to 'Loading the dependent resources...', so that -
whenever we once again show the spinner, it will show that text.
I am considering using the tree events to show the spinner again using the
similar approach used in your first patch.

Then - change the feature test to wait for the spinner to go away before
expanding the table node.

> *Regarding your first patch:*
>>>
>>> Descriptive variable names are clearer than single-letter variable
>>> names. Could you clean up the first patch to use clearer variables, perhaps
>>> add some tests and break it up into methods so that I can more easily
>>> understand what your change does?
>>>
>> Agree.
But - as I said earlier, it represents the data for the tree-item (not the
item itself).
Hence -  it should be 'itemData', and not 'item'.

We've already used 'd' to represent the data, 'i' for item, 't' for tree at
all other places in pgAdmin 4.
So - it is consistent across the application.

I would add comments to understand the functionality a lot better.

Will share the patch for the same.


-- Thanks, Ashesh

> Thank you,
>>>
>>> Tira & George
>>>
>>> On Mon, Mar 20, 2017 at 8:03 AM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> On Mon, Mar 20, 2017 at 10:24 AM, Ashesh Vashi
>>>> <ashesh.va...@enterprisedb.com> wrote:
>>>> > On Fri, Mar 17, 2017 at 8:35 PM, Sarah McAlear <smcal...@pivotal.io>
>>>> wrote:
>>>> >>
>>>> >> Hello,
>>>> >>
>>>> >> We agree that we should keep an eye on this and the failing feature
>>>> tests.
>>>> >> Our current story touches part of this code, but we won't go into
>>>> changing
>>>> >> the library for now.
>>>> >>
>>>> >>

[pgadmin-hackers] pgAdmin 4 commit: [Extendible][Dashboard] Allow to create a server clic

[Ashesh Vashi]

[Extendible][Dashboard] Allow to create a server clicking the
'Add New Server' button on the dashboard, even when the first node is
of not type of 'server-group' in the browser tree.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=90a369b7deb96ad7876b41e851aa0ab7d0bf5c87

Modified Files
--
web/pgadmin/dashboard/templates/dashboard/js/dashboard.js | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Resolved a typo - show a '?' after the 'Show timing'

[Ashesh Vashi]

Resolved a typo - show a '?' after the 'Show timing' preference.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=4eafdbeff6b6c2c05c6934108b8880567798a001

Modified Files
--
web/pgadmin/tools/sqleditor/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: [Extendible][Dashboard] Allow to show the dashboard o

[Ashesh Vashi]

[Extendible][Dashboard] Allow to show the dashboard of their choice for
the selected node in the browser tree.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=72128df75c9d1f298f7a22738f8f81f11b1ed410

Modified Files
--
.../dashboard/templates/dashboard/js/dashboard.js  | 115 +
1 file changed, 51 insertions(+), 64 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Feature test regression failures

[Ashesh Vashi]

On Fri, Mar 17, 2017 at 8:35 PM, Sarah McAlear <smcal...@pivotal.io> wrote:

> Hello,
>
> We agree that we should keep an eye on this and the failing feature tests.
> Our current story touches part of this code, but we won't go into changing
> the library for now.
>
> The patch Tira sent fixes a global variable problem that we found while
> looking into the code that generates the Tree, that
> had the potential to load the tree in an infinite loop.
> Can you apply the patch like this, or would you rather us send it in a
> separate patch email?
>
Name of the variable should have been itemData, d (as earlier), as it
represents the data for the expanding node item.
And, that is not good enough for resolving the issue.

I've two approaches to resolve the idea.
1. Load the nodes (even when the module representing that node is not yet
loaded)
Pros:
- Nodes will be loaded even when the module for the node type is not yet
loaded.
Cons:
- The nodes with modified url (not the default mechanism) may get failed,
if the module is not yet loaded.
  (NOTE: We've not no nodes with that changes at the moment. so - we can
safely ignore it.)
- Operations specific to the nodes will not be honoured until modules is
not loaded.

2. Wait for the modules to get loaded before allowing any operations on
them.
Pros:
- All operations will be done on a node only after the respective module is
loaded.
Cons:
- It will block any operations on pgAdmin 4, when the dependent modules are
being loaded. It can annoy the user.

Please find the patches for both the approaches.

Dave - please take a look at it.

-- Thanks, Ashesh


> Thanks!
> Joao and Sarah
>
> On Thu, Mar 16, 2017 at 10:56 PM, Atira Odhner <aodh...@pivotal.io> wrote:
>
>> We're relying on the third party library jquery.acitree for tree
>>> operations.
>>
>>
>> Yes, what I was suggesting is to probably move away from that. AciTree is
>> one of the libraries my team identified as questionable (not in major
>> repositories, not actively maintained) and there are lots of alternatives.
>>
>> That said, I took a peek at the code and noticed that it was using a
>> global variable ('d') inside the loop where it calculated the tree
>> hierarchy. I suspect that is not the only issue, but here is a patch for it.
>>
>> Tira
>>
>> On Thu, Mar 16, 2017 at 1:39 PM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Mar 16, 2017 22:32, "Atira Odhner" <aodh...@pivotal.io> wrote:
>>>
>>> I have seen this issue as well.
>>>
>>> Ashesh, this issue is related to the loading of the tree node data, not
>>> loading of code, correct?
>>>
>>> Theoritically - Each node may contain code to represent the node url.
>>> For all current nodes follow the function (present in all inherited class
>>> for nodes) to generated URI.
>>>
>>> So - indirectly it relies on the individual node code.
>>>
>>> Each time the user expands a node triggers an ajax request to fetch the
>>> child nodes. There are probably some performance tradeoffs to loading that
>>> tree up front.
>>>
>>> Agree.
>>> That was the reason, we load them only when first parent node (in some
>>> cases grand parent node) is loaded.
>>>
>>> But, there are ways to solve this issue without doing that. We could use
>>> callbacks/promises to wait for things to be loaded before rendering the
>>> node in an enabled/expandable state. It might be helpful to use a one-way
>>> data flow redux pattern to manage the state and rendering of the tree nodes.
>>>
>>> We're relying on the third party library jquery.acitree for tree
>>> operations.
>>> Most operations can be done asynchronous.  But - url generation for
>>> individual node is done using callbacks, which can not work in asynchronous
>>> mode.
>>>
>>> I am thinking of using the 'require' function within that function, when
>>> that node type is not present in the application at that point of time.
>>> Though - I am still not sure, wheather 'require' works that way, or not.
>>>
>>> -- Thanks, Ashesh
>>>
>>> Tira
>>>
>>> On Thu, Mar 16, 2017, 6:49 AM Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> On Thu, Mar 16, 2017 at 10:39 AM, Ashesh Vashi <
>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>
>>>> On Thu, Mar 16, 2017 at 3:55 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>>
>>>> Hi Ashesh,
>>>>
>>>> A

Re: [pgadmin-hackers] Feature test regression failures

[Ashesh Vashi]

On Mar 16, 2017 22:32, "Atira Odhner" <aodh...@pivotal.io> wrote:

I have seen this issue as well.

Ashesh, this issue is related to the loading of the tree node data, not
loading of code, correct?

Theoritically - Each node may contain code to represent the node url. For
all current nodes follow the function (present in all inherited class for
nodes) to generated URI.

So - indirectly it relies on the individual node code.

Each time the user expands a node triggers an ajax request to fetch the
child nodes. There are probably some performance tradeoffs to loading that
tree up front.

Agree.
That was the reason, we load them only when first parent node (in some
cases grand parent node) is loaded.

But, there are ways to solve this issue without doing that. We could use
callbacks/promises to wait for things to be loaded before rendering the
node in an enabled/expandable state. It might be helpful to use a one-way
data flow redux pattern to manage the state and rendering of the tree nodes.

We're relying on the third party library jquery.acitree for tree operations.
Most operations can be done asynchronous.  But - url generation for
individual node is done using callbacks, which can not work in asynchronous
mode.

I am thinking of using the 'require' function within that function, when
that node type is not present in the application at that point of time.
Though - I am still not sure, wheather 'require' works that way, or not.

-- Thanks, Ashesh

Tira

On Thu, Mar 16, 2017, 6:49 AM Dave Page <dp...@pgadmin.org> wrote:

> On Thu, Mar 16, 2017 at 10:39 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
> On Thu, Mar 16, 2017 at 3:55 PM, Dave Page <dp...@pgadmin.org> wrote:
>
> Hi Ashesh,
>
> A common theme is emerging from some of the feature test regression
> failures on the Jenkins server. Please see:
>
> https://jenkins.pgadmin.org/job/pgadmin4-master-python27/
> ws/web/regression/screenshots/EDB_Postgres_AS_9.3/
> ConnectsToServerFeatureTest-2017.03.16_10.09.18-Python-2.7.13.png
>
> I've very occasionally seen similar behaviour to this in the past - in
> fact it's part of the reason why we grey out the UI until pgAdmin is
> fully loaded.
>
> Any idea what might be causing it?
>
> This can happen, when the module is not yet loaded for the respective
> node, and it is being expanded.
> Just thinking - shall we load all the javascript in the beginning?
>
>
> That could be a lot of code, especially as the app grows. It may not be an
> issue in the runtime (though, some recent reports would imply otherwise),
> but it almost certainly would be on slower connections to installations
> running in server mode.
>
> There must be a way to ensure the code is loaded before we allow it to be
> used?
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] Feature test regression failures

[Ashesh Vashi]

On Thu, Mar 16, 2017 at 3:55 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi Ashesh,
>
> A common theme is emerging from some of the feature test regression
> failures on the Jenkins server. Please see:
>
> https://jenkins.pgadmin.org/job/pgadmin4-master-python27/
> ws/web/regression/screenshots/EDB_Postgres_AS_9.3/
> ConnectsToServerFeatureTest-2017.03.16_10.09.18-Python-2.7.13.png
>
> I've very occasionally seen similar behaviour to this in the past - in
> fact it's part of the reason why we grey out the UI until pgAdmin is
> fully loaded.
>
> Any idea what might be causing it?
>
This can happen, when the module is not yet loaded for the respective node,
and it is being expanded.
Just thinking - shall we load all the javascript in the beginning?

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company
<http://www.enterprisedb.com/>


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
>

[pgadmin-hackers] pgAdmin 4 commit: Resolved an issue finding the python interpreter on *

[Ashesh Vashi]

Resolved an issue finding the python interpreter on *nix systems, and
Windows 2008 R2 (32 bit), while running the pgAdmin 4 as runtime for
the PostgreSQL one click installers.

- Found a typo in runtime code, we were appending the path using ';' on
  *nix systems too. We should have used ':', and that did not allow the
  os.environ['PATH'] to identify the correct path of the python
  interpreter under the 'venv' directory.

- On Windows 2008, it was not honouring the environment variables, set
  under the Qt application (e.g. pgAdmin4.exe runtime), in the python
  application. (e.g. pgAdmin4.py). We will need to assume that - the
  python interpreter resides under the 'venv' directory outside the
  'bin' directory.

- Also, on windows 2008, it was setting PYTHONHOME environment variable
  to the full path of the pgAdmin4.exe, we need to reset it to 'venv'
  directory, if we find the python interpreter under it.

Thanks Murtuza Zabuawala for tips, and help.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=7767c085c33d6f230b2ad3e22760a191125ef25d

Modified Files
--
runtime/Server.cpp  | 10 +
web/pgadmin/misc/bgprocess/processes.py | 39 -
2 files changed, 48 insertions(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] [PATCH] Allow to skip the feature tests

[Ashesh Vashi]

Thanks.

--

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 Wed, Mar 8, 2017 at 2:54 PM, Dave Page <dp...@pgadmin.org> wrote:

> Thanks, applied.
>
> On Wed, Mar 8, 2017 at 8:19 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Dave/Team,
>>
>> It is not possible to run the regression testsuite on a machine, where
>> chromium driver is not installed with the current implementation, because -
>> we initialize the selenium webdriver on startup without checking whether it
>> is needed, or not.
>>
>> I have attached the patch to take care of the issue.
>> It skips the webdriver initialization, and other related parameters, if
>> 'feature_tests' is explicitly added in the exclude package list.
>>
>> This will allow us to run the regression-suite using the following
>> command without the need of installing the chromedriver on the host machine.
>> i.e.
>> *python runtests.py --exclude feature_tests*
>>
>> --
>>
>> 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
>

[pgadmin-hackers] [PATCH] Allow to skip the feature tests

[Ashesh Vashi]

Hi Dave/Team,

It is not possible to run the regression testsuite on a machine, where
chromium driver is not installed with the current implementation, because -
we initialize the selenium webdriver on startup without checking whether it
is needed, or not.

I have attached the patch to take care of the issue.
It skips the webdriver initialization, and other related parameters, if
'feature_tests' is explicitly added in the exclude package list.

This will allow us to run the regression-suite using the following command
without the need of installing the chromedriver on the host machine.
i.e.
*python runtests.py --exclude feature_tests*

--

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>


skip_feature_test.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Adding the directory containing 'config.py' in to the

[Ashesh Vashi]

Adding the directory containing 'config.py' in to the sys.path variable,
so that - when config.py refered from outside the pgAdmin itself (i.e.
during building the pip).

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=41e0a73ea6e361e772323a5d9130505bb89380ef

Modified Files
--
web/config.py | 9 +
1 file changed, 9 insertions(+)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Import config only when needed, it was causing cyclic

[Ashesh Vashi]

Import config only when needed, it was causing cyclic dependency when
running the regression suite.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=6cc1fbe73976fd5b3dcb2c4597f3699f8e1c56aa

Modified Files
--
web/pgadmin/utils/paths.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Resolved quite a few file-system encoding/decoding re

[Ashesh Vashi]

Resolved quite a few file-system encoding/decoding related cases.

In order to resolve the non-ascii characters in path (in user directory,
storage path, etc) on windows, we have converted the path into the
short-path, so that - we don't need to deal with the encoding issues
(specially with Python 2).

We've resolved majority of the issues with this patch.
We still need couple issues to resolve after this in the same area.

TODO
* Add better support for non-ascii characters in the database name on
  windows with Python 3
* Improve the messages created after the background processes by
  different modules (such as Backup, Restore, Import/Export, etc.),
  which does not show short-paths, and xml representable characters for
  non-ascii characters, when found in the database objects, and the file
  PATH.

Fixes #2174, #1797, #2166, #1940

Initial patch by: Surinder Kumar
Reviewed by: Murtuza Zabuawala

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=f2fc1ceba884d56307e69e2febd6035f6f248995

Modified Files
--
web/config.py  |  45 +++--
web/pgAdmin4.py|   8 +-
web/pgadmin/__init__.py|  14 +-
web/pgadmin/misc/bgprocess/process_executor.py | 243 +++--
web/pgadmin/misc/bgprocess/processes.py|  90 +
web/pgadmin/tools/backup/__init__.py   | 109 ++-
web/pgadmin/tools/import_export/__init__.py| 167 +
web/pgadmin/tools/restore/__init__.py  |  78 
web/pgadmin/utils/__init__.py  | 102 +++
web/pgadmin/utils/driver/psycopg2/__init__.py  |  10 +-
web/pgadmin/utils/html.py  |  11 +-
web/pgadmin/utils/paths.py |   6 +-
web/pgadmin/utils/preferences.py   |   2 +-
web/pgadmin/utils/session.py   |   5 +-
web/setup.py   |  71 +---
15 files changed, 599 insertions(+), 362 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Better handling the non-ascii characters for differen

[Ashesh Vashi]

Better handling the non-ascii characters for different database objects.

Using 'psycopg2.extensions.UNICODE' (for Python < 3) in the psycopg2
driver for proper conversation of unicode characters. Also - adjusted
the string typecaster to take care of different character types (char,
character, text, name, character varying, and their array types).

Reviewed by: Dave Page, Murtuza Zabuawala & Akshay Joshi

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ffa8d94e76be344429b57fd88ccfe5b224fdd136
Author: Harshal Dhumal 

Modified Files
--
.../server_groups/servers/databases/__init__.py|   8 +-
.../servers/databases/casts/__init__.py|  25 +++---
.../servers/databases/event_triggers/__init__.py   |  46 +-
.../databases/foreign_data_wrappers/__init__.py|   5 +-
.../foreign_servers/__init__.py|   4 +-
.../foreign_servers/user_mapping/__init__.py   |   4 +-
.../servers/databases/schemas/__init__.py  |   8 +-
.../databases/schemas/collations/__init__.py   |   5 +-
.../servers/databases/schemas/domains/__init__.py  |   7 +-
.../schemas/domains/domain_constraints/__init__.py |   7 +-
.../databases/schemas/foreign_tables/__init__.py   |   8 +-
.../schemas/fts_configurations/__init__.py |  26 +++---
.../databases/schemas/fts_dictionaries/__init__.py |  25 +++---
.../templates/fts_dictionary/sql/default/sql.sql   |   8 +-
.../databases/schemas/fts_parser/__init__.py   |  24 +++--
.../templates/fts_parser/sql/default/sql.sql   |   8 +-
.../databases/schemas/fts_templates/__init__.py|  12 +--
.../templates/fts_template/sql/default/sql.sql |   8 +-
.../databases/schemas/functions/__init__.py|  39 ++--
.../servers/databases/schemas/packages/__init__.py |   4 +-
.../schemas/packages/edbfuncs/__init__.py  |   4 +-
.../databases/schemas/packages/edbvars/__init__.py |   8 +-
.../servers/databases/schemas/tables/__init__.py   |  37 
.../constraints/check_constraint/__init__.py   |   4 +-
.../constraints/exclusion_constraint/__init__.py   |   4 +-
.../tables/constraints/foreign_key/__init__.py |  85 +-
.../constraints/index_constraint/__init__.py   |  73 +++
.../databases/schemas/tables/indexes/__init__.py   |  45 +-
.../schemas/tables/templates/rules/sql/create.sql  |   4 +-
.../databases/schemas/tables/triggers/__init__.py  |  71 +++
.../servers/databases/schemas/types/__init__.py|   4 +-
.../servers/databases/schemas/views/__init__.py|  19 +++-
.../server_groups/servers/tablespaces/__init__.py  |   5 +-
web/pgadmin/utils/driver/psycopg2/__init__.py  | 100 ++---
34 files changed, 364 insertions(+), 380 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Patch from RM1983 [pgAdmin4]

[Ashesh Vashi]

On Wed, Mar 1, 2017 at 10:27 PM, Dave Page  wrote:

> You're going to deal with the final review/commit right Ashesh?
>
Yes - I am planning to.

>
> On Wed, Mar 1, 2017 at 11:41 AM, Murtuza Zabuawala
>  wrote:
> > Hi,
> >
> > Patch looks good to me, Tested with Python3.5(manually) attached
> screenshot
> > & Python2.7 (using TestSuite).
> >
> > --
> > Regards,
> > Murtuza Zabuawala
> > EnterpriseDB: http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> >
> > On Tue, Feb 28, 2017 at 1:24 PM, Harshal Dhumal
> >  wrote:
> >>
> >> Hi,
> >>
> >> Please find updated patch for encoding issue.
> >>
> >> Apart from encoding issue I have also fixed issue of wrong data was show
> >> in query editor for string types and array string types for databases
> with
> >> encoding other than utf-8.
> >>
> >>
> >>
> >> --
> >> Harshal Dhumal
> >> Software Engineer
> >>
> >> EnterpriseDB India: http://www.enterprisedb.com
> >> The Enterprise PostgreSQL Company
> >>
> >> On Fri, Feb 24, 2017 at 4:41 PM, Dave Page  wrote:
> >>>
> >>> Hi
> >>>
> >>> On Thu, Feb 23, 2017 at 10:34 AM, Harshal Dhumal
> >>>  wrote:
> >>> > Hi,
> >>> >
> >>> > Please find updated patch for unicode issue on python 2.7
> >>> >
> >>> > I have tested with below scenarios for all nodes (except database and
> >>> > Login/Group Role as these are stored in shared catalogs as for now we
> >>> > are
> >>> > not considering encoding issues for these two nodes)
> >>>
> >>> This breaks on my PG 9.4 server - I'm unable to open the Databases
> >>> node. That server has both databases with Unicode names, and databases
> >>> in encodings other than UTF-8.
> >>>
> >>> (hat-tip to George and Atira; it was their feature tests that showed
> >>> up this problem :-) )
> >>>
> >>> 2017-02-24 11:08:26,379: INFO werkzeug: 127.0.0.1 - - [24/Feb/2017
> >>> 11:08:26] "GET /browser/database/nodes/1/1/ HTTP/1.1" 500 -
> >>> Traceback (most recent call last):
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 2000, in __call__
> >>> return self.wsgi_app(environ, start_response)
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1991, in wsgi_app
> >>> response = self.make_response(self.handle_exception(e))
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1567, in handle_exception
> >>> reraise(exc_type, exc_value, tb)
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1988, in wsgi_app
> >>> response = self.full_dispatch_request()
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1641, in full_dispatch_request
> >>> rv = self.handle_user_exception(e)
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1544, in handle_user_exception
> >>> reraise(exc_type, exc_value, tb)
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1639, in full_dispatch_request
> >>> rv = self.dispatch_request()
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/app.py",
> >>> line 1625, in dispatch_request
> >>> return self.view_functions[rule.endpoint](**req.view_args)
> >>>   File
> >>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-
> packages/flask/views.py",
> >>> line 84, in view
> >>> return self.dispatch_request(*args, **kwargs)
> >>>   File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/utils.py", line
> >>> 235, in dispatch_request
> >>> return method(*args, **kwargs)
> >>>   File
> >>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_
> groups/servers/databases/__init__.py",
> >>> line 151, in wrapped
> >>> return f(self, *args, **kwargs)
> >>>   File
> >>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_
> groups/servers/databases/__init__.py",
> >>> line 228, in nodes
> >>> res = self.get_nodes(gid, sid)
> >>>   File
> >>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_
> groups/servers/databases/__init__.py",
> >>> line 198, in get_nodes
> >>> dbname = dbname.decode('utf-8')
> >>>   File
> >>> "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/encodings/utf_8.py",
> >>> line 16, in decode
> >>> return codecs.utf_8_decode(input, errors, True)
> >>> UnicodeEncodeError: 'ascii' codec can't encode characters in position
> >>> 0-5: ordinal not in range(128)
> >>>
> >>>
> >>>
> >>> --
> >>> Dave Page
> >>> Blog: http://pgsnake.blogspot.com
> >>> Twitter: @pgsnake
> >>>
> >>> EnterpriseDB UK: http://www.enterprisedb.com
> >>> The Enterprise PostgreSQL Company
> >>
> >>
> >>
> >>
> >> --

[pgadmin-hackers] PATCH: Javascript addons/modules specific to pgAdmin 4

[Ashesh Vashi]

Hi Dave,

We've added few add-ons for CodeMirror, and slickgrid to be used by pgAdmin
4.
Moved them back to 'static/js' directory from 'vendor' directory.

--

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>


pgadmin_specific_js.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Feature test issues

[Ashesh Vashi]

On Mon, Feb 27, 2017 at 9:32 AM, Atira Odhner <aodh...@pivotal.io> wrote:

> Cool, we already have a task about proper teardown and a couple other
> things in our backlog. we'll probably get to it in the next day or so. I'll
> take a look at the other stuff.
>
> Also, regarding speed, even without the app startup time, end to end tests
> are always going to be relatively slow. We definitely want to make sure
> that the time it takes to run the tests does not grow to where it is a
> deterrent to running them.
> There are a variety of things we can do to help address that as our suite
> grows. For instance,  we could consider parallelizing the tests, making
> setup and teardown more efficient,  combining related tests, or even
> breaking the tests into suites and running only some of them locally by
> default.
> Since we only have a couple feature tests so far the speed hasn't really
> felt like an issue for me yet, but I understand it may be different if you
> are trying to run in a variety of configurations.
>
> Out of curiosity, what is the goal in supporting multiple python versions?
>
We support Python 2.6, 2.7, 3.3+.

> Are we working on moving to 3.x and just haven't gotten fully there yet?
>
There is no plan to move to Python 3 only.
We do support Python 2.6 too, so that - it works on system like Cento OS 6+
out of box.

We (at EnterpriseDB) test pgAdmin 4 with Python 2.6, 2.7, 3.3, 3.4, 3.5 &
3.6.

--
Thanks,
Ashesh Vashi

> Tira
>
> On Sun, Feb 26, 2017, 3:39 AM Dave Page <dp...@pgadmin.org> wrote:
>
>> Hi Tira, George,
>>
>> I've just been updating our internal automated test system to run the
>> feature tests, and ran into a couple of additional issues that need to
>> be addressed. Can you look into the following please?
>>
>> - When starting pgAdmin, it's using the default configuration database
>> (CONFIG['SQLITE_PATH']), however for testing we should be using
>> CONFIG['TEST_SQLITE_PATH']). This means that it's polluting the user's
>> default configuration (and if they don't have one, causing an
>> additional initialisation step).
>>
>> - With Python 2.6, the following failure is seen when the first
>> feature test is run:
>>
>> Traceback (most recent call last):
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/web/
>> regression/runtests.py",
>> line 286, in 
>> verbosity=2).run(suite)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/runner.py",
>> line 172, in run
>> test(result)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py",
>> line 87, in __call__
>> return self.run(*args, **kwds)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py",
>> line 126, in run
>> test(result)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py",
>> line 673, in __call__
>> return self.run(*args, **kwds)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py",
>> line 633, in run
>> self._feedErrorsToResult(result, outcome.errors)
>>   File "/var/lib/jenkins/workspace/pgadmin4-master-python26/
>> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py",
>> line 563, in _feedErrorsToResult
>> if issubclass(exc_info[0], self.failureException):
>> TypeError: issubclass() arg 2 must be a class or tuple of classes
>>
>> For completeness, other issues outstanding that we've previously
>> discussed:
>>
>> - pgAdmin processes may remain running after test failures.
>>
>> - The test suite may hang following a feature test failure, at the end
>> of the run.
>>
>> - The screenshot functionality should be fixed (ideally) or removed.
>>
>> - The tests really need to run with a single instantiation of pgAdmin.
>> It's clearly going to be far too slow to start/stop pgAdmin for every
>> test once we start adding more (and moving forward, I really want
>> feature tests to become the default to ensure we're end-to-end testing
>> everything). For reference, each test run (currently one version of
>> Python, against 5 different database servers) is now taking ~5 minutes
>> vs. 1m47s without the feature tests.
>>
>> On the plus side, test runs are now green across the board with
>> feature tests enabled, except for Python 2.6 :-)
>>
>> Thanks!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

Re: [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Hi Dave,

Please find the patch with fix for the 2144.

--

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 Fri, Feb 3, 2017 at 11:02 AM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> RM reported:
> https://redmine.postgresql.org/issues/2144
>
>
> On Fri, Feb 3, 2017 at 10:11 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Can you please create a separate RM for the same, and assign it to me?
>> And, please attach the pgadmin logs (only the relevant logs).
>>
>> --
>>
>> 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 Fri, Feb 3, 2017 at 10:36 AM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> Hi Ashesh,
>>>
>>> I tested this patch with Import/Export table, backup database, backup
>>> table, backup server and Backup global, it working fine. While in case of
>>> Restore database, it failed and "sequence item 6: expected string or
>>> Unicode, int found"  message displayed.
>>>
>>> Kind Regards
>>>
>>> On Thu, Feb 2, 2017 at 9:14 PM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
>>>> On Thu, Feb 2, 2017 at 6:19 PM, Fahar Abbas <
>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Currently Ashesh is working  for the particular issue on my machine
>>>>> and he will share the updated patch on tomorrow.
>>>>>
>>>> Thanks Fahar for your help to figure out the actual issue.
>>>>
>>>> Please find the updated patch.
>>>> I've added logging functionality in the process executor permanently.
>>>>
>>>> Working as expected with the latest patch on my systems (OSX, and
>>>> Window 10).
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> Ashesh Vashi
>>>>
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> On Thu, Feb 2, 2017 at 11:22 AM, Fahar Abbas <
>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>
>>>>>> Sure Ashesh,
>>>>>>
>>>>>> I will test and update the testing status accordingly.
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 11:17 AM, Ashesh Vashi <
>>>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Hi Fahar,
>>>>>>>
>>>>>>> Can you please test the updated patch?
>>>>>>> I have fixed one issue on windows, and also added logging
>>>>>>> information in the background process execution for future issue 
>>>>>>> analysis.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> 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 Mon, Jan 23, 2017 at 12:19 PM, Fahar Abbas <
>>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> Hi Murtaza,
>>>>>>>>
>>>>>>>> I am using Administrator user on 2012 server . Can you please check
>>>>>>>> this behavior on my machine through skype or google talk?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 23, 2017 at 10:07 AM, Murtuza Zabuawala <
>>>>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>> I tested with Python-2.7 on Windows10 (32-bit) & on MacOS I tested
>>>>>>>>&g

Re: [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Can you please create a separate RM for the same, and assign it to me?
And, please attach the pgadmin logs (only the relevant logs).

--

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 Fri, Feb 3, 2017 at 10:36 AM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Hi Ashesh,
>
> I tested this patch with Import/Export table, backup database, backup
> table, backup server and Backup global, it working fine. While in case of
> Restore database, it failed and "sequence item 6: expected string or
> Unicode, int found"  message displayed.
>
> Kind Regards
>
> On Thu, Feb 2, 2017 at 9:14 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Thu, Feb 2, 2017 at 6:19 PM, Fahar Abbas <fahar.ab...@enterprisedb.com
>> > wrote:
>>
>>> Hi,
>>>
>>> Currently Ashesh is working  for the particular issue on my machine and
>>> he will share the updated patch on tomorrow.
>>>
>> Thanks Fahar for your help to figure out the actual issue.
>>
>> Please find the updated patch.
>> I've added logging functionality in the process executor permanently.
>>
>> Working as expected with the latest patch on my systems (OSX, and Window
>> 10).
>>
>> --
>> Thanks & Regards,
>>
>> Ashesh Vashi
>>
>>>
>>> Kind Regards,
>>>
>>> On Thu, Feb 2, 2017 at 11:22 AM, Fahar Abbas <
>>> fahar.ab...@enterprisedb.com> wrote:
>>>
>>>> Sure Ashesh,
>>>>
>>>> I will test and update the testing status accordingly.
>>>>
>>>> On Thu, Feb 2, 2017 at 11:17 AM, Ashesh Vashi <
>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Fahar,
>>>>>
>>>>> Can you please test the updated patch?
>>>>> I have fixed one issue on windows, and also added logging information
>>>>> in the background process execution for future issue analysis.
>>>>>
>>>>> --
>>>>>
>>>>> 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 Mon, Jan 23, 2017 at 12:19 PM, Fahar Abbas <
>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Murtaza,
>>>>>>
>>>>>> I am using Administrator user on 2012 server . Can you please check
>>>>>> this behavior on my machine through skype or google talk?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 23, 2017 at 10:07 AM, Murtuza Zabuawala <
>>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> I tested with Python-2.7 on Windows10 (32-bit) & on MacOS I tested
>>>>>>> with Python3.5 (64-bit), It is working as expected,
>>>>>>>
>>>>>>> I suspect that as you are running with Server 2012, permissions
>>>>>>> might be the issue, Can you try running with Administrator?
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Murtuza Zabuawala
>>>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>> On Sat, Jan 21, 2017 at 1:18 AM, Fahar Abbas <
>>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> I tested in Google chrome Windows 2012 R2 64 with Python 2.7.11. It
>>>>>>>> might be possible that you tested on Python 3+.
>>>>>>>>
>>>>>>>> Please confirm?
>>>>>>>>
>>>>>>>> On Fri, Jan 20, 2017 at 6:49 PM, Murtuza Zabuawala <
>>>>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>> That's strange.
>>>>>>>>>
>>>>>>>>> I 

Re: [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

On Thu, Feb 2, 2017 at 6:19 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Hi,
>
> Currently Ashesh is working  for the particular issue on my machine and he
> will share the updated patch on tomorrow.
>
Thanks Fahar for your help to figure out the actual issue.

Please find the updated patch.
I've added logging functionality in the process executor permanently.

Working as expected with the latest patch on my systems (OSX, and Window
10).

--
Thanks & Regards,

Ashesh Vashi

>
> Kind Regards,
>
> On Thu, Feb 2, 2017 at 11:22 AM, Fahar Abbas <fahar.ab...@enterprisedb.com
> > wrote:
>
>> Sure Ashesh,
>>
>> I will test and update the testing status accordingly.
>>
>> On Thu, Feb 2, 2017 at 11:17 AM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Hi Fahar,
>>>
>>> Can you please test the updated patch?
>>> I have fixed one issue on windows, and also added logging information in
>>> the background process execution for future issue analysis.
>>>
>>> --
>>>
>>> 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 Mon, Jan 23, 2017 at 12:19 PM, Fahar Abbas <
>>> fahar.ab...@enterprisedb.com> wrote:
>>>
>>>> Hi Murtaza,
>>>>
>>>> I am using Administrator user on 2012 server . Can you please check
>>>> this behavior on my machine through skype or google talk?
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On Mon, Jan 23, 2017 at 10:07 AM, Murtuza Zabuawala <
>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>
>>>>> I tested with Python-2.7 on Windows10 (32-bit) & on MacOS I tested
>>>>> with Python3.5 (64-bit), It is working as expected,
>>>>>
>>>>> I suspect that as you are running with Server 2012, permissions might
>>>>> be the issue, Can you try running with Administrator?
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Murtuza Zabuawala
>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> On Sat, Jan 21, 2017 at 1:18 AM, Fahar Abbas <
>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>
>>>>>> I tested in Google chrome Windows 2012 R2 64 with Python 2.7.11. It
>>>>>> might be possible that you tested on Python 3+.
>>>>>>
>>>>>> Please confirm?
>>>>>>
>>>>>> On Fri, Jan 20, 2017 at 6:49 PM, Murtuza Zabuawala <
>>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> That's strange.
>>>>>>>
>>>>>>> I tested in Chrome, Need check in IE.
>>>>>>>
>>>>>>> Meanwhile can try with Chrome/Firefox?
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Murtuza Zabuawala
>>>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>> On Fri, Jan 20, 2017 at 7:01 PM, Fahar Abbas <
>>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> Hi Murtaza,
>>>>>>>>
>>>>>>>> I just applied this patch and issue is still not resolved.
>>>>>>>>
>>>>>>>> In case of Maintenance DB and Backup database message, *Maintenance
>>>>>>>> job created* and *Backup job created*  displayed but no other
>>>>>>>> dialogue box displayed either process is completed or not.
>>>>>>>>
>>>>>>>> Screen-shot and pgadmin.log file is attached.
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 20, 2017 at 5:35 PM, Murtuza Zabuawala <
>>>>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Fahar,
>>>>

Re: [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Hi Fahar,

Can you please test the updated patch?
I have fixed one issue on windows, and also added logging information in
the background process execution for future issue analysis.

--

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 Mon, Jan 23, 2017 at 12:19 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Hi Murtaza,
>
> I am using Administrator user on 2012 server . Can you please check this
> behavior on my machine through skype or google talk?
>
> Regards,
>
>
> On Mon, Jan 23, 2017 at 10:07 AM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> I tested with Python-2.7 on Windows10 (32-bit) & on MacOS I tested with
>> Python3.5 (64-bit), It is working as expected,
>>
>> I suspect that as you are running with Server 2012, permissions might be
>> the issue, Can you try running with Administrator?
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Sat, Jan 21, 2017 at 1:18 AM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> I tested in Google chrome Windows 2012 R2 64 with Python 2.7.11. It
>>> might be possible that you tested on Python 3+.
>>>
>>> Please confirm?
>>>
>>> On Fri, Jan 20, 2017 at 6:49 PM, Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
>>>> That's strange.
>>>>
>>>> I tested in Chrome, Need check in IE.
>>>>
>>>> Meanwhile can try with Chrome/Firefox?
>>>>
>>>> --
>>>> Regards,
>>>> Murtuza Zabuawala
>>>> EnterpriseDB: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> On Fri, Jan 20, 2017 at 7:01 PM, Fahar Abbas <
>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Murtaza,
>>>>>
>>>>> I just applied this patch and issue is still not resolved.
>>>>>
>>>>> In case of Maintenance DB and Backup database message, *Maintenance
>>>>> job created* and *Backup job created*  displayed but no other
>>>>> dialogue box displayed either process is completed or not.
>>>>>
>>>>> Screen-shot and pgadmin.log file is attached.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>>
>>>>> On Fri, Jan 20, 2017 at 5:35 PM, Murtuza Zabuawala <
>>>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Fahar,
>>>>>>
>>>>>> Could you please test this updated patch?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Murtuza Zabuawala
>>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>> On Tue, Jan 17, 2017 at 3:45 PM, Fahar Abbas <
>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Thanks Dave.
>>>>>>>
>>>>>>> On Tue, Jan 17, 2017 at 3:07 PM, Dave Page <dp...@pgadmin.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Not surprising. Don't bother testing that any more for now thanks.
>>>>>>>> I suspect it's a simple bug that Ashesh can fix pronto.
>>>>>>>>
>>>>>>>> On Tue, Jan 17, 2017 at 10:02 AM, Fahar Abbas <
>>>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>> Issue is also reproducible with PG-9.6 server.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 17, 2017 at 2:55 PM, Fahar Abbas <
>>>>>>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>>>>>>
>>>>>>>>>> Please attached the log files output from the terminal and
>>>>>>>>>> pgAdmin4.log.
>>>>>>>>>>
>>>>>>>>>> Kind Regards,
>>>>>>>>>

Re: [pgadmin-hackers] [pgAdmin4][Patch] Minor fix in test file for the Template loader

[Ashesh Vashi]

Murtuza,

FYI -
http://www.diveintopython3.net/porting-code-to-python-3-with-2to3.html#itertools

--

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 Tue, Jan 31, 2017 at 3:34 PM, Dave Page <dp...@pgadmin.org> wrote:

> Thanks Murtuza. When you get a minute, can you also look at the
> following issue I get with the tests under Python 3.5? It doesn't seem
> to stop them working.
>
> Traceback (most recent call last):
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/route.py", line
> 75, in load_generators
> import_module(module_name)
>   File "/Users/dpage/.virtualenvs/pgadmin4-py35/lib/python3.5/
> importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 986, in _gcd_import
>   File "", line 969, in _find_and_load
>   File "", line 958, in
> _find_and_load_unlocked
>   File "", line 673, in _load_unlocked
>   File "", line 673, in exec_module
>   File "", line 222, in
> _call_with_frames_removed
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/
> sqlautocomplete/counter.py",
> line 6, in 
> from itertools import repeat, ifilter
> ImportError: cannot import name 'ifilter'
>
>
> On Tue, Jan 31, 2017 at 5:25 AM, Murtuza Zabuawala
> <murtuza.zabuaw...@enterprisedb.com> wrote:
> > Hi,
> >
> > PFA patch to fix the issue in test suite for template loader.
> >
> > Issue(Python3):
> > murtuza@vm:~/pgadmin4/web/regression$ python3 runtests.py
> > pgAdmin 4 - Application Initialisation
> > ==
> >
> >
> > The configuration database - '/../.pgadmin/test_pgadmin4.db' does not
> exist.
> > Entering initial setup mode...
> > NOTE: Configuring authentication for SERVER mode.
> >
> >
> > The configuration database has been created at
> /../.pgadmin/test_pgadmin4.db
> > Traceback (most recent call last):
> >   File "runtests.py", line 250, in 
> > test_module_list = get_test_modules(args)
> >   File "runtests.py", line 138, in get_test_modules
> > TestsGeneratorRegistry.load_generators('pgadmin')
> >   File "../../pgadmin4/web/pgadmin/utils/route.py", line 66, in
> > load_generators
> > import_module(module_name)
> >   File "/../../3.5/lib/python3.5/importlib/__init__.py", line 126, in
> > import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> >   File "", line 986, in _gcd_import
> >   File "", line 969, in _find_and_load
> >   File "", line 958, in
> _find_and_load_unlocked
> >   File "", line 673, in _load_unlocked
> >   File "", line 658, in
> exec_module
> >   File "", line 764, in get_code
> >   File "", line 724, in
> source_to_code
> >   File "", line 222, in
> > _call_with_frames_removed
> >   File
> > "/../../pgadmin4/web/pgadmin/utils/tests/test_versioned_
> template_loader.py",
> > line 50
> > except TemplateNotFound, e:
> >^
> > SyntaxError: invalid syntax
> >
> > --
> > Regards,
> > Murtuza Zabuawala
> > EnterpriseDB: http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> >
> >
> > --
> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgadmin-hackers
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

decorated_view
> return func(*args, **kwargs)
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/__init__.py",
> line 70, in index
> return make_response(response=BatchProcess.list())
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/processes.py",
> line 415, in list
> status, updated = BatchProcess.update_process_info(p)
>   File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/processes.py",
> line 390, in update_process_info
> if data['end_time']:
> KeyError: u'end_time'
>
> The status file contains:
>
> {"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
> "exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>

Thanks for reviewing the patch.
Please find the updated patch.

Changes:
- Using now ValueError instead of json.JSONDecodeError, which is subclass
of ValueError, to allow to it to work with 2.6+ python.
- Checking the existence of value in dict before accessing it.

--

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 Tue, Jan 10, 2017 at 5:47 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Team,
>>
>> In new implementation - we are forking the process-executor on the POSIX
>> system to run the process in true daemon mode.
>> And, we were updating the status in the configuration file (which is
>> sqlite database), it was crashing while opening the configuration file, and
>> couldn't update the status.
>> Reference: https://bugs.python.org/issue27126
>>
>> In order to resolve the issue, we're now creating a 'status' file for the
>> process information.
>> And, it will be used to check the status information about the process.
>>
>> Thanks Dave for helping find out the root cause of the issue, and point
>> out the correct reference point.
>> Please find the updated patch with the latest changes.
>>
>> I have also attached a patch to make the restore, and backup routes more
>> REST API compatible.
>>
>> --
>>
>> 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 Mon, Dec 19, 2016 at 5:28 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> On Mon, Dec 19, 2016 at 11:52 AM, Dave Page <dp...@pgadmin.org> wrote:
>>> >
>>> >
>>> > On Fri, Dec 16, 2016 at 10:16 AM, Ashesh Vashi
>>> > <ashesh.va...@enterprisedb.com> wrote:
>>> >>
>>> >> Hi Dave,
>>> >>
>>> >> On Mon, Dec 12, 2016 at 4:01 PM, Dave Page <dp...@pgadmin.org> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> On Fri, Dec 9, 2016 at 9:16 AM, Ashesh Vashi
>>> >>> <ashesh.va...@enterprisedb.com> wrote:
>>> >>>>
>>> >>>> Hi Dave,
>>> >>>>
>>> >>>> Please find the patch to resolve the issue reported in RM #1679
>>> >>>>
>>> >>>> This will take care of:
>>> >>>> - Find the appropriate available Python interpreter to execute the
>>> >>>> process_executor.py.
>>> >>>>   In case of WSGI or Runtime, it was not properly find the
>>> interpreter
>>> >>>> required to execute that script. Also, on windows - we should give
>>> priority
>>> >>>> to the windowless python interpreter (if available).
>>> >>>> - Execute the process_executor.py script with proper platform
>>> dependent
>>> >>>> flags to run it as daemon.
>>> >>>> - Run the process_executor.py in proper daemon mode. It helps to
>>> run the
>>> >>>> long running processes like backup, restore, etc.
>>> >>>>   On windows, run the process_executor.py from process_executor.py
>>> in
>>> >>>> detached mode to allow the child process to run in detached mode.
>>> >>>>   On POSIX, fork the process_executor.py to allow the child process
>>> to
>>> >>>> run in daemon mode.
>>> >>>>   Also - listen the signal like SIGINT, SIGTERM, 

[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Hi Team,

In new implementation - we are forking the process-executor on the POSIX
system to run the process in true daemon mode.
And, we were updating the status in the configuration file (which is sqlite
database), it was crashing while opening the configuration file, and
couldn't update the status.
Reference: https://bugs.python.org/issue27126

In order to resolve the issue, we're now creating a 'status' file for the
process information.
And, it will be used to check the status information about the process.

Thanks Dave for helping find out the root cause of the issue, and point out
the correct reference point.
Please find the updated patch with the latest changes.

I have also attached a patch to make the restore, and backup routes more
REST API compatible.

--

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 Mon, Dec 19, 2016 at 5:28 PM, Dave Page <dp...@pgadmin.org> wrote:

> On Mon, Dec 19, 2016 at 11:52 AM, Dave Page <dp...@pgadmin.org> wrote:
> >
> >
> > On Fri, Dec 16, 2016 at 10:16 AM, Ashesh Vashi
> > <ashesh.va...@enterprisedb.com> wrote:
> >>
> >> Hi Dave,
> >>
> >> On Mon, Dec 12, 2016 at 4:01 PM, Dave Page <dp...@pgadmin.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Fri, Dec 9, 2016 at 9:16 AM, Ashesh Vashi
> >>> <ashesh.va...@enterprisedb.com> wrote:
> >>>>
> >>>> Hi Dave,
> >>>>
> >>>> Please find the patch to resolve the issue reported in RM #1679
> >>>>
> >>>> This will take care of:
> >>>> - Find the appropriate available Python interpreter to execute the
> >>>> process_executor.py.
> >>>>   In case of WSGI or Runtime, it was not properly find the interpreter
> >>>> required to execute that script. Also, on windows - we should give
> priority
> >>>> to the windowless python interpreter (if available).
> >>>> - Execute the process_executor.py script with proper platform
> dependent
> >>>> flags to run it as daemon.
> >>>> - Run the process_executor.py in proper daemon mode. It helps to run
> the
> >>>> long running processes like backup, restore, etc.
> >>>>   On windows, run the process_executor.py from process_executor.py in
> >>>> detached mode to allow the child process to run in detached mode.
> >>>>   On POSIX, fork the process_executor.py to allow the child process to
> >>>> run in daemon mode.
> >>>>   Also - listen the signal like SIGINT, SIGTERM, so that - the child
> >>>> does not kill, or hangup (It used to happen.
> >>>>
> >>>>
> >>>> NOTE:
> >>>> This patch does not take care of the unicode errors in the path. I
> will
> >>>> send a separate patch for the same.
> >>>
> >>>
> >>> Unfortunately my first test of this failed:
> >>>
> >>> SERVER_MODE = False
> >>> Python 2.7.11 (Mac default)
> >>> Running in Chrome
> >>>
> >>> I ran a backup of a database, and got the green backup initiated
> popup...
> >>> then, nothing. Upon checking my config, I found I had the PostgreSQL
> Bin
> >>> Path set to "$DIR/a/b/c", which clearly won't work. So, we're not yet
> >>> detecting failure to start a process properly.
> >>
> >> During exception handling, the logger's encoding was not set properly
> >> during initialisation,  that was resulting into an error.
> >>
> >> Also - sometime the process execution does not start quickly enough to
> >> list down the process execution properly.
> >> Hence - we should check the process list after some time.
> >>
> >> Please find the update patch with the above both problems resolved.
> >
> >
> > Same results with the new patch - either with a correct bin path or an
> > incorrect one, I see the green notification that the backup has started,
> > then nothing.
> >
> > Sidenote: I don't even see anything at all in the console output. I
> think we
> > should at least spit out a debug message showing the command line we're
> > executing the launcher with, and ideally include any other details we can
> > such as job IDs etc.
>
> BTW; attached is my process table from the SQLite database.
>
> I believe the last two rows are from my test today. The out and err
> logs for both are empty files.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


tools_rest_api.patch
Description: Binary data


RM1679_v6.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Hi Dave,

On Mon, Dec 12, 2016 at 4:01 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi,
>
> On Fri, Dec 9, 2016 at 9:16 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Please find the patch to resolve the issue reported in RM #1679
>> <https://redmine.postgresql.org/issues/1679>
>>
>> This will take care of:
>> - Find the appropriate available Python interpreter to execute the
>> process_executor.py.
>>   In case of WSGI or Runtime, it was not properly find the interpreter
>> required to execute that script. Also, on windows - we should give priority
>> to the windowless python interpreter (if available).
>> - Execute the process_executor.py script with proper platform dependent
>> flags to run it as daemon.
>> - Run the process_executor.py in proper daemon mode. It helps to run the
>> long running processes like backup, restore, etc.
>>   On windows, run the process_executor.py from process_executor.py in
>> detached mode to allow the child process to run in detached mode.
>>   On POSIX, fork the process_executor.py to allow the child process to
>> run in daemon mode.
>>   Also - listen the signal like SIGINT, SIGTERM, so that - the child does
>> not kill, or hangup (It used to happen.
>>
>>
>> NOTE:
>> This patch does not take care of the unicode errors in the path. I will
>> send a separate patch for the same.
>>
>
> Unfortunately my first test of this failed:
>
> SERVER_MODE = False
> Python 2.7.11 (Mac default)
> Running in Chrome
>
> I ran a backup of a database, and got the green backup initiated popup...
> then, nothing. Upon checking my config, I found I had the PostgreSQL Bin
> Path set to "$DIR/a/b/c", which clearly won't work. So, we're not yet
> detecting failure to start a process properly.
>
During exception handling, the logger's encoding was not set properly
during initialisation,  that was resulting into an error.

Also - sometime the process execution does not start quickly enough to list
down the process execution properly.
Hence - we should check the process list after some time.

Please find the update patch with the above both problems resolved.


--

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>

>
> I then corrected the path to "/Library/PostgreSQL/9.6/bin", and re-ran the
> backup. That didn't work either - I saw exactly the same result as before,
> a green popup, then nothing.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


RM1679_v4.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin

[Ashesh Vashi]

Hi Dave,

Please find the patch to resolve the issue reported in RM #1679
<https://redmine.postgresql.org/issues/1679>

This will take care of:
- Find the appropriate available Python interpreter to execute the
process_executor.py.
  In case of WSGI or Runtime, it was not properly find the interpreter
required to execute that script. Also, on windows - we should give priority
to the windowless python interpreter (if available).
- Execute the process_executor.py script with proper platform dependent
flags to run it as daemon.
- Run the process_executor.py in proper daemon mode. It helps to run the
long running processes like backup, restore, etc.
  On windows, run the process_executor.py from process_executor.py in
detached mode to allow the child process to run in detached mode.
  On POSIX, fork the process_executor.py to allow the child process to run
in daemon mode.
  Also - listen the signal like SIGINT, SIGTERM, so that - the child does
not kill, or hangup (It used to happen.


NOTE:
This patch does not take care of the unicode errors in the path. I will
send a separate patch for the same.

--

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>


RM1679_v2.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] pgadmin4. utf8 bug report

[Ashesh Vashi]

Hi,

What is the operating system user name?

On Dec 3, 2016 06:40, "Андрей Брюхов"  wrote:

> I'm using binary:
>
>- pgAdmin4: 1.1
>- python: 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC
>v.1500 32 bit (Intel)]
>- Flask Version: 0.11.
>
>
> I have a table:
>
> CREATE DATABASE test
> WITH
> OWNER = postgres
> ENCODING = 'UTF8'
> LC_COLLATE = 'Russian_Russia.1251'
> LC_CTYPE = 'Russian_Russia.1251'
> TABLESPACE = pg_default
> CONNECTION LIMIT = -1;
>
> with no any rows.
>
> Table containg next columns:
>
> ALTER TABLE public.machine
> ADD COLUMN id integer NOT NULL;
>
> ALTER TABLE public.machine
> ADD COLUMN name character varying(256) COLLATE pg_catalog."default";
>
> ALTER TABLE public.machine
> ADD COLUMN vendor character varying(256) COLLATE pg_catalog."default";
>
> ALTER TABLE public.machine
> ADD COLUMN type_id integer;
>
> ALTER TABLE public.machine
> ADD COLUMN model_id integer;
>
> ALTER TABLE public.machine
> ADD COLUMN serial_number character varying(256) COLLATE
> pg_catalog."default";
>
> ALTER TABLE public.machine
> ADD COLUMN software_version character varying(255) COLLATE
> pg_catalog."default";
>
> ALTER TABLE public.machine
> ADD COLUMN matrix_id integer;
>
> When i click 'backup' on menu:
>
> Backing up an object on the server 'vending (127.0.0.1:5432)' from
> database 'test'...
> Running command:
> C:\Program Files\PostgreSQL\9.6\bin\pg_dump.exe --file "C:/Intel/123"
> --host "127.0.0.1" --port "5432" --username "postgres" --no-password
> --verbose --format=p "test"
>
> Start time: Fri Dec 02 2016 17:56:05 GMT+0300 (RTZ 2 (зима))
> 'utf8' codec can't decode byte 0xe2 in position 30: invalid continuation
> byte
>

Re: [pgadmin-hackers] [pgAdmin4][Patch]: Fixed RM 1603 & RM 1220

[Ashesh Vashi]

On Thu, Oct 20, 2016 at 4:26 PM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Sat, Oct 15, 2016 at 11:52 AM, Dave Page <dp...@pgadmin.org> wrote:
>
>>
>>
>> On Friday, October 14, 2016, Ashesh Vashi <ashesh.va...@enterprisedb.com>
>> wrote:
>>
>>> On Sat, Oct 15, 2016 at 4:59 AM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> Hi
>>>>
>>>> On Friday, October 14, 2016, Khushboo Vashi <
>>>> khushboo.va...@enterprisedb.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please find the attached patch to fix the below 2 bugs.
>>>>>
>>>>> RM 1603: [Web Based] Export database failed if object contains double
>>>>> quotes.
>>>>> RM 1220: Backup database is not working with special characters
>>>>>
>>>>> The issues which were fixed:
>>>>>
>>>>> 1. Client side data were not unescaped
>>>>> 2. Required command line arguments were quoted twice
>>>>>
>>>>
>>>> This is not working for me: I tested using Table Export as per Fahar's
>>>> instructions. As I'm in desktop mode, the first problem was that we get an
>>>> error at line 210 of import_export/__init__.py, because
>>>> get_server_directory returned None for the directory. If I fix that, then
>>>> the job says it's created, but as far as I can see, nothing else happens.
>>>>
>>> hmm..
>>>
>>
>> Yes, but please see my followup message. There's clearly something funky
>> going on with the process tracking - for whatever reason it didn't pick up
>> this process until after a restart, and per the bug I escalated earlier
>> (which I think is essential to fix for 1.1 in a little over a week), it
>> doesn't always detect completed processes and then keeps re-showing the
>> alert.
>>
>>
>
> The problem here is that, until we click the "Click for details here" link
> and close the another details dialogue, the acknowledgement does not send
> to the server. So, it keeps re-showing the alert.
>
> I think, we need to clearly mention the steps on the alertify notifier
> itself, so the user can get the idea.
>
> Dave/Ashesh,
> Any other suggestion?
>
We can give a acknowledge link along with 'Click here for details' link to
delete the status, logs, when clicked.
Dave?

>
>
>>
>>>> Secondly, this patch seems to push quoting responsibilty to the front
>>>> end.
>>>>
>>> No - that's not the case, we're using _.escape(..) function on the
>>> node's label to fix the issue of XSS vulnerability on client side.
>>> Hence - during sending back the data, we're using _.unescape(..)
>>> function to return the same data coming sent by the server.
>>>
>>
>> Ahh, OK - I see.
>>
>>
>>>
>>> Though - IIRC - we have a original label stored in another variable
>>> '_label', which we can use it instead of unescape it again.
>>>
>>
>> Right, as we've done in many other places.
>>
>
> I have replaced  _. unescape with _label
>
>
>>
>>> This doesn't seem right, because we might want to use the RESTful APIs
>>>> for another purpose in the future, which would mean needing to re-implement
>>>> quoting if something else uses an affected API.
>>>>
>>> As I explained above, it wont affect the RESTful API.
>>>
>>
>> Yep. Thanks for setting me straight.
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>

Re: [pgadmin-hackers] RM1849: Auto-generating security keys

[Ashesh Vashi]

You were missing the other places, before the function - do_setup(..) call,
where we are generating the other keys automatically.
I've checked-in the code.

Fahar,

If you want to test the issue properly, please follow the below steps:
- git checkout c4f1b8eb112e99d228c40a412020fa616dbe44f6
  This was the commit-id, where we have the configuration schema version
'13'.
- Delete the existing pgadmin4.db
- Set CSRF_SESSION_KEY, SECRET_KEY, SECURITY_PASSWORD_SALT in
config_local.py.
- Execute the command - 'python setup.py'.
- Now - you've configuration file with old schema.
- 'git checkout master' to go to the latest code.
- Make sure - you've latest code. 'git pull'.
- Now - rerun 'python setup.py/pgAdmin4.py'. It should work.


--

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 Thu, Oct 20, 2016 at 11:15 AM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hi,
>
> PFA patch to fix the issue for Pyhton3.
> RM#1849
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abbas <
> fahar.ab...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> I have reopened following RM:
>> 
>> https://redmine.postgresql.org/issues/1849
>>
>> On Wed, Oct 19, 2016 at 6:04 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> Patch applied.
>>>
>>> On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
>>>> Hi Fahar,
>>>>
>>>> Please log the case on redmine.
>>>> Please find the attached patch, please apply it locally, and test it.
>>>>
>>>> And, please update the case, and this mail chain accordingly.
>>>>
>>>> --
>>>>
>>>> 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 Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas <
>>>> fahar.ab...@enterprisedb.com> wrote:
>>>>
>>>>> Here is the output of if we copy config_local.py and execute python
>>>>> setup.py
>>>>> pgAdmin 4 - Application Initialisation
>>>>> ==
>>>>>
>>>>>
>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does
>>>>> not exist.
>>>>> Entering initial setup mode...
>>>>> NOTE: Configuring authentication for SERVER mode.
>>>>>
>>>>>
>>>>> Enter the email address and password to use for the initial
>>>>> pgAdmin user account:
>>>>>
>>>>> Email address: fahar.ab...@enterprisedb.com
>>>>> Password:
>>>>> Retype password:
>>>>> Traceback (most recent call last):
>>>>>   File "setup.py", line 449, in 
>>>>> do_setup(app)
>>>>>   File "setup.py", line 96, in do_setup
>>>>> password = encrypt_password(p1)
>>>>>   File 
>>>>> "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
>>>>> line 150, in encrypt_password
>>>>> signed = get_hmac(password).decode('ascii')
>>>>>   File 
>>>>> "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
>>>>> line 108, in get_hmac
>>>>> 'set to "%s"' % _security.password_hash)
>>>>> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must
>>>>> not be None when the value of `SECURITY_PASSWORD_HASH` is set to
>>>>> "pbkdf2_sha512"
>>>>> python setup.py
>>>>> pgAdmin 4 - Application Initialisation
>>>>> ==
>>>>>
>>>>> User can not do any setup for web based now.
>>>>>
>>>>>
>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does
>>>>> not exist.
>>>>> Entering initial 

[pgadmin-hackers] pgAdmin 4 commit: Ensure the auto-generated CSRF_SESSION_KEY, SECRET_KE

[Ashesh Vashi]

Ensure the auto-generated CSRF_SESSION_KEY, SECRET_KEY,
SECURITY_PASSWORD_SALT keys are decoded as string for python 3
compatibility.

Fixes #1871

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=d4c439d64ae9ba638cb7698a7dd8340b9a0a5857

Modified Files
--
web/setup.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] RM1849: Auto-generating security keys

[Ashesh Vashi]

On Thu, Oct 20, 2016 at 1:00 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Murtaza,
>
> Once i delete key table from pgAdmin4.db file then i can launch pgAdmin4
> with terminal as well as web browser for existing pgAdmin4 setup.
>
>
> In case of fresh setup once we delete key table and apply latest patch
> following message displayed:
>
> python pgAdmin4.py
> Traceback (most recent call last):
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 1139, in _execute_context
> context)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py",
> line 450, in do_execute
> cursor.execute(statement, parameters)
> sqlite3.OperationalError: no such table: keys
>
That's because - you've not yet update the ConfigDB to 13 in the version
table in the sqlite configuration table.

And, the next exception, you're describing, is result of that.

--

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>


>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "pgAdmin4.py", line 46, in 
> app = create_app()
>   File "/home/fahar/Projects/pgadmin4/web/pgadmin/__init__.py", line 224,
> in create_app
> config.CSRF_SESSION_KEY = Keys.query.filter_by(name =
> 'CSRF_SESSION_KEY').first().value
>   File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py",
> line 2659, in first
> ret = list(self[0:1])
>   File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py",
> line 2457, in __getitem__
> return list(res)
>   File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py",
> line 2761, in __iter__
> return self._execute_and_instances(context)
>   File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py",
> line 2776, in _execute_and_instances
> result = conn.execute(querycontext.statement, self._params)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 914, in execute
> return meth(self, multiparams, params)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/sql/elements.py",
> line 323, in _execute_on_connection
> return connection._execute_clauseelement(self, multiparams, params)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 1010, in _execute_clauseelement
> compiled_sql, distilled_params
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 1146, in _execute_context
> context)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 1341, in _handle_dbapi_exception
> exc_info
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py",
> line 202, in raise_from_cause
> reraise(type(exception), exception, tb=exc_tb, cause=cause)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py",
> line 185, in reraise
> raise value.with_traceback(tb)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py",
> line 1139, in _execute_context
> context)
>   File 
> "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py",
> line 450, in do_execute
> cursor.execute(statement, parameters)
> sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such
> table: keys [SQL: 'SELECT keys.name AS keys_name, keys.value AS
> keys_value \nFROM keys \nWHERE keys.name = ?\n LIMIT ? OFFSET ?']
> [parameters: ('CSRF_SESSION_KEY', 1, 0)]
>
>
> On Thu, Oct 20, 2016 at 11:00 AM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Could you delete 'keys' table from pgadmin4.db file & try again?
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Thu, Oct 20, 2016 at 11:26 AM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> Murtaza,
>>>
>>> I have applied this patch and there is no success on new pgAdmin4 setup
>>> as well as existing pgAdmin4 setup.
>>>
>>> On Thu, Oct 20, 2016 at 10:45 AM, Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> 

Re: [pgadmin-hackers] RM1849: Auto-generating security keys

[Ashesh Vashi]

Hi Fahar,

Please log the case on redmine.
Please find the attached patch, please apply it locally, and test it.

And, please update the case, and this mail chain accordingly.

--

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 Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Here is the output of if we copy config_local.py and execute python
> setup.py
> pgAdmin 4 - Application Initialisation
> ==
>
>
> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not
> exist.
> Entering initial setup mode...
> NOTE: Configuring authentication for SERVER mode.
>
>
> Enter the email address and password to use for the initial pgAdmin
> user account:
>
> Email address: fahar.ab...@enterprisedb.com
> Password:
> Retype password:
> Traceback (most recent call last):
>   File "setup.py", line 449, in 
> do_setup(app)
>   File "setup.py", line 96, in do_setup
> password = encrypt_password(p1)
>   File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
> line 150, in encrypt_password
> signed = get_hmac(password).decode('ascii')
>   File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
> line 108, in get_hmac
> 'set to "%s"' % _security.password_hash)
> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be
> None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
> python setup.py
> pgAdmin 4 - Application Initialisation
> ==
>
> User can not do any setup for web based now.
>
>
> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not
> exist.
> Entering initial setup mode...
> NOTE: Configuring authentication for SERVER mode.
>
>
> Enter the email address and password to use for the initial pgAdmin
> user account:
>
> Email address: fahar.ab...@enterprisedb.com
> Password:
> Retype password:
> Traceback (most recent call last):
>   File "setup.py", line 449, in 
> do_setup(app)
>   File "setup.py", line 96, in do_setup
> password = encrypt_password(p1)
>   File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
> line 150, in encrypt_password
> signed = get_hmac(password).decode('ascii')
>   File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py",
> line 108, in get_hmac
> 'set to "%s"' % _security.password_hash)
> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be
> None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
>
> On Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas <fahar.ab...@enterprisedb.com
> > wrote:
>
>> Dave,
>>
>> Testing Environment
>>
>> Ubuntu 16.04 Linux 64:
>> 
>>
>> pg-AdminIV Development Environment Setup for Ubuntu  :
>>
>>
>> 1) Install GIT
>>
>> sudo apt-get install git
>>
>> 2) Install pip3
>>
>> sudo apt-get install python3-pip
>>
>> 3) Install virtualenv
>>
>> sudo pip3 install virtualenv
>>
>> 4) install below dependency as it is required for psycopg2 & pycrypto
>> module
>>
>> sudo apt-get install libpq-dev
>>
>> sudo apt-get install python3-dev
>>
>> 5) Create virtual environment
>>
>> virtualenv -p python3 venv
>>
>> 6) Create mkdir Projects
>>
>> 7) Clone git repo in Projects
>>
>> git clone http://git.postgresql.org/git/pgadmin4.git
>>
>> 8) activate virtual environment
>>
>> source venv/bin/activate
>>
>> 9) Install modules
>>
>> pip3 install -r requirements_py3.txt
>>
>> *10) Edit the config.py file to config_local.py  resides in
>> Projects\pgAdmin4\web *
>>
>> 11)Now run setup.py file  (\Projects\pgAdmin4\web)
>> python setup.py
>>
>> If user does not create config_local.py and do Python setup.py for new
>> Development then SECURITY_PASSWORD_SALT message is also displayed:
>>
>> Here is the output:
>> -
>>
>> python setup.py
>> pgAdmin 4 - Application Initialisation
>> ==
>>
>>
>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not
>>

[pgadmin-hackers] pgAdmin 4 commit: Resolved - Integer type of preferences are not update

[Ashesh Vashi]

Resolved - Integer type of preferences are not updated

Reason: IntegerControl assumes the model, passed to it, would always has 
errorModel variable set properly.

In order to resolve it, now using pgBrowser.DataModel instead of 
Backbone.Model, which initialize the errorModel by default.

Fixes #1868

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=b17eb157423043352a948b38e3eb703cb45c5698

Modified Files
--
web/pgadmin/preferences/templates/preferences/preferences.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] RM1849: Auto-generating security keys

[Ashesh Vashi]

Hi Dave,

On Sat, Oct 15, 2016 at 8:02 AM, Dave Page <dp...@pgadmin.org> wrote:

> Hi
>
>
> On Friday, October 14, 2016, Dave Page <dp...@pgadmin.org> wrote:
>
>> Hi
>>
>> On Thursday, October 13, 2016, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dp...@pgadmin.org> wrote:
>>>
>>>> Hi Ashesh,
>>>>
>>>> Can you please review the attached patch, and apply if you're happy
>>>> with it?
>>>>
>>> Overall the patch looked good to me.
>>> But - I encounter an issue in 'web' mode, which wont happen with
>>> 'runtime'.
>>>
>>> Steps for reproduction on existing pgAdmin 4 environment with 'web' mode.
>>> - Apply the patch
>>> - Start the pgAdmin4 application (stand alone application).
>>> - Open pgAdmin home page.
>>> - Log out (if already login).
>>>
>>> And, you will see an exception.
>>>
>>> I have figure out the issue with the patch.
>>> We were setting the SECURITY_PASSWORD_SALT, after initializing the
>>> Security object.
>>> Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT
>>> properly.
>>>
>>
>> Hmm.
>>
>>
>>>
>>> I had moved the Security object initialization after fetching these
>>> configurations from the database.
>>> I have attached a addon patch for the same.
>>>
>>
>> OK, thanks.
>>
>>
>>>
>>> Now - I run into another issue.
>>> Because - the existing password was hashed using the old
>>> SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4.
>>>
>>> I think - we need to think about different strategy for upgrading the
>>> configuration file in the 'web' mode.
>>> I was thinking - we can store the existing security configurations in
>>> the database during upgrade process in 'web' mode.
>>>
>>
>> My concern with that is that we'll likely be storing the default config
>> values in many cases, thus for those users, perpetuating the problem.
>>
>> I guess what we need to do is re-encrypt the password during the upgrade
>> - however, that makes me think; we then have both the key and the encrypted
>> passwords in the same database which is clearly not a good idea. Sigh...
>> Needs more thought.
>>
>
> OK, so I've been thinking about this and experimenting for a couple of
> hours, as well as annoying the crap out of Magnus by thinking out loud in
> his general direction, and it looks like this isn't a major problem as from
> what I can see,  SECURITY_PASSWORD_SALT is (aside from really being a key
> not a salt) not the only salting that's done.
>
> It looks like it's used system-wide as the key to generate an HMAC of the
> users password, which is then passed to passlib which salts and hashes it.
> I did some testing, and found that two users with the same password end up
> with different hashes in the database, so clearly there is also per-user
> salting happening. I also created two users, then dropped the database and
> created the same user accounts with the same passwords again, and found
> that the resulting hashes were different in both databases - thus there is
> something else ensuring the hashes are unique across different
> installations/databases.
>
> So, I believe we can do as you suggest and migrate existing values for
> SECURITY_PASSWORD_SALT, given that there's clearly some other per user and
> per installation/database salting going on anyway. New installations can
> have the random value for SECURITY_PASSWORD_SALT.
>
We do not need to generate the random SECURITY_PASSWORD_SALT during upgrade
mode, which was wrong added in my addon patch.

Please find the updated patch.

Otherwise - looks good to me.
Please commit the new patch (if you're ok with the change).


--

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>

>
> I don't believe SECURITY_KEY and CSRF_SESSION_KEY are issues either, as
> they're used for purposes that are essentially ephemeral, and thus can be
> changed during an upgrade.
>
> Adding Magnus as I'd appreciate any thoughts he may have.
>
> Patch attached - please review (Ashesh, but others too would be
> appreciated)!
>
> Thanks.
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>


auto_generate_security_keys_v3.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] [pgAdmin4][Patch]: Fixed RM 1603 & RM 1220

[Ashesh Vashi]

On Sat, Oct 15, 2016 at 4:59 AM, Dave Page <dp...@pgadmin.org> wrote:

> Hi
>
> On Friday, October 14, 2016, Khushboo Vashi <khushboo.vashi@enterprisedb.
> com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to fix the below 2 bugs.
>>
>> RM 1603: [Web Based] Export database failed if object contains double
>> quotes.
>> RM 1220: Backup database is not working with special characters
>>
>> The issues which were fixed:
>>
>> 1. Client side data were not unescaped
>> 2. Required command line arguments were quoted twice
>>
>
> This is not working for me: I tested using Table Export as per Fahar's
> instructions. As I'm in desktop mode, the first problem was that we get an
> error at line 210 of import_export/__init__.py, because
> get_server_directory returned None for the directory. If I fix that, then
> the job says it's created, but as far as I can see, nothing else happens.
>
hmm..

>
> Secondly, this patch seems to push quoting responsibilty to the front end.
>
No - that's not the case, we're using _.escape(..) function on the node's
label to fix the issue of XSS vulnerability on client side.
Hence - during sending back the data, we're using _.unescape(..) function
to return the same data coming sent by the server.

Though - IIRC - we have a original label stored in another variable
'_label', which we can use it instead of unescape it again.

> This doesn't seem right, because we might want to use the RESTful APIs for
> another purpose in the future, which would mean needing to re-implement
> quoting if something else uses an affected API.
>
As I explained above, it wont affect the RESTful API.

--
Thanks & Regards,

Ashesh Vashi

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

Re: [pgadmin-hackers] RM1849: Auto-generating security keys

[Ashesh Vashi]

Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi Ashesh,
>
> Can you please review the attached patch, and apply if you're happy with
> it?
>
Overall the patch looked good to me.
But - I encounter an issue in 'web' mode, which wont happen with 'runtime'.

Steps for reproduction on existing pgAdmin 4 environment with 'web' mode.
- Apply the patch
- Start the pgAdmin4 application (stand alone application).
- Open pgAdmin home page.
- Log out (if already login).

And, you will see an exception.

I have figure out the issue with the patch.
We were setting the SECURITY_PASSWORD_SALT, after initializing the Security
object.
Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT
properly.

I had moved the Security object initialization after fetching these
configurations from the database.
I have attached a addon patch for the same.

Now - I run into another issue.
Because - the existing password was hashed using the old
SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4.

I think - we need to think about different strategy for upgrading the
configuration file in the 'web' mode.
I was thinking - we can store the existing security configurations in the
database during upgrade process in 'web' mode.

I was not able to spend much time on it due to some other priorities.

--
Thanks & Regards,
Ashesh Vashi


> The purpose is to auto-generate the various security keys that are
> currently in the configuration file, and store them in the SQLite database.
> This allows us to remove the checks for config_local.py and the hard-coded
> default keys which are causing some problems with packaging:
>
> - Hard coded defaults are fine for Desktop mode, and packages generally
> aim to make that work primarily.
> - Hard coded defaults are a security risk for Server mode, hence we
> currently require the user to manually setup keys, which is currently being
> overridden by packagers for Desktop mode.
>
> This change ensures that we have unique security keys for every
> installation, whether running in desktop or server mode (generated from
> os.urandom).
>
> Thanks!
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>


add_auto_generate_security_keys.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Connection to the server has been lost

[Ashesh Vashi]

On Tue, Oct 4, 2016 at 1:00 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Please also remember to add pgAdmin-hackers email list for every email in
> that case, Development team can respond quickly.
>
> Dave/Ashesh,
>
> Please find below the output shared by Ralph.
>
> Kind Regards,
>
>
> On Tue, Oct 4, 2016 at 12:24 PM, Ralph Ryl <ralph@thuenen.de> wrote:
>
>> Hi Fahar,
>>
>> here are the steps I do:
>>
>> - System: Ubuntu 14.04
>>
>> - I create an new server in a servergroup wich is not local
>>
>> - I enter correct logindata
>>
>> - if i directly try to connect an error with "bytea_output" appear
>>
>> - if i save the connection without directly connect it save the connection
>>
>> - if i doubleclick on the new connection pgadmin ask for the password(no
>> matter if i save it) and show an message like "Connection to the server has
>> been lost."
>>
> Hi Ralph,

Looks like - pgAdmin 4 (indirectly the psycopg2 driver) is using very old
version of libpq.

Can you please upgrade the libpq on the system?
I will be able to suggest "how to upgrade on libpq", only if you can give
information about the operating system?

--

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>

>
>> here the last 50 lines from the logfile:
>>
>> 2016-10-04 09:20:37,847: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:20:37] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:20:42,858: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:20:42] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:20:47,869: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:20:47] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:20:52,879: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:20:52] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:20:57,891: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:20:57] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:02,902: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:02] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:07,912: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:07] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:12,924: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:12] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:16,626: INFOpgadmin:Connection Request for server#4
>>
>> 2016-10-04 09:21:16,629: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:16] "POST /browser/server/connect/2/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:17,935: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:17] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:18,188: INFOpgadmin:Connection Request for server#4
>>
>> 2016-10-04 09:21:18,211: SQLpgadmin:Execute (scalar) for server #4 - 
>> DB:postgres (Query-id: 8568684):
>>
>> SET DateStyle=ISO;
>>
>> SET client_min_messages=notice;
>>
>> SET bytea_output=escape;
>>
>> SET client_encoding='UNICODE';
>>
>> 2016-10-04 09:21:18,214: ERRORpgadmin:Failed to execute query 
>> (execute_scalar) for the server #4 - DB:postgres (Query-id: 8568684):
>>
>> Error Message:FEHLER:  unbekannter Konfigurationsparameter »bytea_output«
>>
>> 2016-10-04 09:21:22,946: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:22] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:27,959: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:27] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:31,139: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:31] "POST /misc/ping HTTP/1.1" 200 -
>>
>> 2016-10-04 09:21:32,973: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:32] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:37,986: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:37] "GET /dashboard/activity/4 HTTP/1.1" 428 -
>>
>> 2016-10-04 09:21:43,001: INFOwerkzeug:127.0.0.1 - - [04/Oct/2016 
>> 09:21:43] "GET /dashboard/activity/4 HTTP/1.1" 4

[pgadmin-hackers] pgAdmin 4 commit: Fixes# 1808 - Invalid date-time format was used in th

[Ashesh Vashi]

Fixes# 1808 - Invalid date-time format was used in the Start/End time
for Job Schedule.

Thanks Susan for the report.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=e52aeecd20324135fd4ace15187cb3250359e995

Modified Files
--
.../schedules/templates/pga_schedule/js/pga_schedule.js  | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Fwd: Bug Report, pgAdmin 4 RC1, Windows 10.1607

[Ashesh Vashi]

Hi Erez,

Please avoid sending personal mail, and keep the pgadmin-hackers list in CC
(preferably - 'Reply All').
This would also solve the user's having same issue in future.

--

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 Thu, Sep 29, 2016 at 6:00 PM, Fahar Abbas <fahar.ab...@enterprisedb.com>
wrote:

> Adding Ashesh and Dave.
>
> Please also share pgAdmin.log file  to the team and they can further debug
> this:
>
> C:\Users\Fahar Abbas\AppData\Roaming\pgAdmin
>
>
> On Thu, Sep 29, 2016 at 3:22 PM, Erez Segal <erezse...@gmail.com> wrote:
>
>> Hmm... Is there any way to get debug info and see why I get "Not
>> connected" error (only on the query tool)?
>>
>> On Thu, Sep 29, 2016 at 10:19 AM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> Hi Eraz,
>>>
>>> I am not able to reproduce that issue on Windows 10 64 bit. It might be
>>> your machine specific issue.
>>>
>>> I checked this issue on PostgreSQL-9.6.0 and pgAdmin4 v 1.0 and that is
>>> releasing soon.
>>>
>>> Please check the snapshot for a reference.
>>>
>>> Kind Regards,
>>>
>>> On Wed, Sep 28, 2016 at 11:17 PM, Erez Segal <erezse...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>> I'm running pgAdmin 4 rc1 on Windows 10.1607.
>>>> I can connect to my server (PostgreSQL 9.5.4) and choose my database. I
>>>> then open the query tool and send a query. I have two errors:
>>>>
>>>> 1. The program UI is stuck until the query returns
>>>> [image: Inline image 1]
>>>>
>>>> 2. I get this message, even though I just connected, chose a DB and
>>>> opened the query tool
>>>> [image: Inline image 2]
>>>>
>>>> * I'm also using pgAdmin III and it works - but I really wanted to
>>>> check out the new UI
>>>>
>>>> It might also be the place to say the one feature I'm missing in
>>>> pgAdmin III is the ability to have more then 1 Data Output window.
>>>>
>>>> Thanks!
>>>>
>>>> Erez
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Syed Fahar Abbas
>>> Quality Management Group
>>>
>>> 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
>>>
>>
>>
>
>
> --
> Syed Fahar Abbas
> Quality Management Group
>
> 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
>

Re: [pgadmin-hackers] [pgAdmin4][Patch]: Error while expanding server group node.

[Ashesh Vashi]

On Mon, Sep 26, 2016 at 6:54 PM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Hi
>
> *Issue:*
> Getting following error while expanding server group node.
> File "/Users/surinder/Documents/Projects/pgadmin4/web/pgadmin/
> browser/server_groups/servers/__init__.py", line 86, in get_nodes
> in_recovery = result['rows'][0]['inrecovery'];
> TypeError: string indices must be integers
>
> Not a proper scenario to reproduce it.
>
> *Solution:*
> Add proper check to fix it.
>

Thanks - committed!

--

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>


>
>
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>

[pgadmin-hackers] pgAdmin 4 commit: Do not try to set in_recovery, is_replay_paused prope

[Ashesh Vashi]

Do not try to set in_recovery, is_replay_paused properties in the server
object, when data is not available.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0ae719dae00324c49ea777d8194ca2860f4af471
Author: Surinder Kumar 

Modified Files
--
web/pgadmin/browser/server_groups/servers/__init__.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] pgAdmin 4 commit: Fixes#1737 - Setting the schedma-id as the pid (paren

[Ashesh Vashi]

Fixes#1737 - Setting the schedma-id as the pid (parent-id) for the
sequences node instead of the server-id.

Due to this - during updating the sequence node, it was not able to find
out the correct parent node, and it was updating the existing node, but
- later it (considering the old node) was removed by the replace logic.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=1c623c56e7cafc0df28913390761bef1231c1064

Modified Files
--
.../server_groups/servers/databases/schemas/sequences/__init__.py| 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] PATCH: RM#1735

[Ashesh Vashi]

Hi Team,


On Sat, Sep 24, 2016 at 3:23 AM, Ashesh Vashi <ashesh.va...@enterprisedb.com
> wrote:

> Hi Dave/Team,
>
> I've fixed the issue "No default schema when creating some schema objects".
>
> For package, allowing to change the schema at the create time only, as the
> logic required to change schema of an existing package required a lot of
> changes. And, I am reluctant to do it at this phase of the project.
>
I also find out that - when we refresh the schema node, it was returning an
array of node data instead of an individual node data.

Please find the fix for it as part # 2.

NOTE: First patch is still applicable.

--

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>

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


RM1735_part2.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] PATCH: RM#1733

[Ashesh Vashi]

Hi Dave/Team,

Please find the patch for the issue - 'Filter option taking too much time
to load'.
Actually - it wasn't taking any time, but - we did not hide the loading div
properly.

Please find the patch, which also takes care of other similar possible
issue along with the above issue.

--

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>


RM1733.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] PATCH: RM#1736

[Ashesh Vashi]

Hi Dave/Team,

Please find the patch for the "Cannot create a view".
When we do not select the schema name, this error comes at backend-side.

The client-side issue has been taken care by the patch for RM#1735.

--

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>


RM1736.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] PATCH: RM#1735

[Ashesh Vashi]

Hi Dave/Team,

I've fixed the issue "No default schema when creating some schema objects".

For package, allowing to change the schema at the create time only, as the
logic required to change schema of an existing package required a lot of
changes. And, I am reluctant to do it at this phase of the project.

--

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>


RM1735.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] PATCH: pgAgent support

[Ashesh Vashi]

Thanks - working on the rest of the comments.

--

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 Fri, Sep 23, 2016 at 2:40 PM, Dave Page <dp...@pgadmin.org> wrote:

> Thanks, applied.
>
> On Fri, Sep 23, 2016 at 7:33 AM, Ashesh Vashi
> <ashesh.va...@enterprisedb.com> wrote:
> > Hi Dave,
> >
> >
> > On Thu, Sep 22, 2016 at 8:01 PM, Dave Page <dp...@pgadmin.org> wrote:
> >>
> >> Hi
> >>
> >> On Thu, Sep 22, 2016 at 11:47 AM, Ashesh Vashi
> >> <ashesh.va...@enterprisedb.com> wrote:
> >>>
> >>> Hi Dave,
> >>>
> >>> Please find the patch for support for paAgent in pgAdmin 4.
> >>
> >>
> >> Did you forget the binary switch?
> >>
> >> piranha:web dpage$ git apply --binary ~/Downloads/pgagent_v2.patch
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/coll-pga_schedule.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/coll-pga_schedule.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/pga_schedule.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/pga_schedule.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/coll-pga_job.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/coll-pga_job.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job-disabled.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job-disabled.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/coll-pga_jobstep.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/coll-pga_jobstep.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/pga_jobstep.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/pga_jobstep.png:
> >> patch does not apply
> >>>
> >>>
> >>> I have also attached another patch for miscellaneous fixes, and adding
> >>> new controls.
> >>> It includes:
> >>> - Added DatetimepickerControl, MomentCell (using moment.js)
> >>> - Used the 'DatetimepickerControl' in Role (Also - resolved an issue,
> >>> when unset the datetime for 'Valid Until'.)
> >>> - Added a 'Select All/Unselect All' adaptor for Select2 used by pgAgent
> >>> nodes.
> >>> - Fixed an issue with SubNodeCollectionControl, which was not starting
> >>> the modification session of the child model, when created default
> value for
> >>> collection is not null/undefined. And, hence - validation on the child
> model
> >>> was not working.
> >>> - Fixed a memory leak with SqlFieldControl, and SqlTabControl, which
> was
> >>> not releasing the CodeMirror properly.
> >>
> >>
> >> Urgh, that's big.
> >
> > I know.
> > That's reason - I was reluctant to send earlier.
> >>
> >> Applied - but can you look at the following please?
> >>
> >> - Account expires has a hint of 'MMM D  HH:mm:ss.SSS Z". Are
> >> milliseconds really needed? I also get 00 as a fractional timezone
> offset.
> >> Perhaps we should hide that, when it's 00?
> >
> > Changed to '-MM-DD HH:mm:ss Z'.
> >>
> >>
> >> - The date format differs from the ISO format displayed by the query
> tool.
> >> They should be consistent - and really should be either based on the
> >> client's locale settings, or ISO format.
> >
> > Done
> >
> > --
> > Thanks & Regards,
> >
> > Ashesh Vashi
> >>
> >>
> >> 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
>

Re: [pgadmin-hackers] [pgAdmin4][Patch]: Background process executor won't run(in case of Backup, restore) in Windows only

[Ashesh Vashi]

On Fri, Sep 23, 2016 at 1:54 PM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Fri, Sep 23, 2016 at 9:18 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Fri, Sep 23, 2016 at 1:47 PM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>> On Fri, Sep 23, 2016 at 5:59 AM, Surinder Kumar
>>> <surinder.ku...@enterprisedb.com> wrote:
>>> > Actually It doesn't broke anywhere, instead It runs successfully. On
>>> > debugging I found that it runs the subprocess.Popen() utility but it
>>> doesn't
>>> > run internally the pg_dump utitliy. On running the same command on
>>> windows
>>> > cmd prompt it works.
>>> > Then on setting parameters close_fds=False and cmd_shell=True, It
>>> works.
>>> > I ran backup in Google Chrome.
>>>
>>> It certainly runs pg_dump for me - I see the output in the monitoring
>>> dialogue, and I get a dump file at the end.
>>>
>>> I also use Chrome.
>>>
>> It may differ for different version of python.
>>
>
> Maybe. I'm using 2.7.
>
> Either way, I don't want a command window flashing up unnecessarily.
>
If we set the PYTHON INTERPRETER to run the background process.
i.e. BG_PYTHON_INTERPRETER=c:\Python27\pythonw.exe

We can avoid showing the flashing command window.
I came to this conclusion, because - I tried to hide them using certain
flags, but - it wasn't working well.

--

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: [pgadmin-hackers] [pgAdmin4][Patch]: Background process executor won't run(in case of Backup, restore) in Windows only

[Ashesh Vashi]

On Fri, Sep 23, 2016 at 1:47 PM, Dave Page <dp...@pgadmin.org> wrote:

> On Fri, Sep 23, 2016 at 5:59 AM, Surinder Kumar
> <surinder.ku...@enterprisedb.com> wrote:
> > Actually It doesn't broke anywhere, instead It runs successfully. On
> > debugging I found that it runs the subprocess.Popen() utility but it
> doesn't
> > run internally the pg_dump utitliy. On running the same command on
> windows
> > cmd prompt it works.
> > Then on setting parameters close_fds=False and cmd_shell=True, It works.
> > I ran backup in Google Chrome.
>
> It certainly runs pg_dump for me - I see the output in the monitoring
> dialogue, and I get a dump file at the end.
>
> I also use Chrome.
>
It may differ for different version of python.


--

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
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

Re: [pgadmin-hackers] PATCH: pgAgent support

[Ashesh Vashi]

Hi Dave,


On Thu, Sep 22, 2016 at 8:01 PM, Dave Page <dp...@pgadmin.org> wrote:

> Hi
>
> On Thu, Sep 22, 2016 at 11:47 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Please find the patch for support for paAgent in pgAdmin 4.
>>
>
> Did you forget the binary switch?
>
> piranha:web dpage$ git apply --binary ~/Downloads/pgagent_v2.patch
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/schedules/static/img/coll-pga_schedule.png'
> without full index line
> error: web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/coll-pga_schedule.png: patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/schedules/static/img/pga_schedule.png' without
> full index line
> error: web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/pga_schedule.png: patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/static/img/coll-pga_job.png' without full index
> line
> error: 
> web/pgadmin/browser/server_groups/servers/pgAgent/static/img/coll-pga_job.png:
> patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/static/img/pga_job-disabled.png' without full
> index line
> error: 
> web/pgadmin/browser/server_groups/servers/pgAgent/static/img/pga_job-disabled.png:
> patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/static/img/pga_job.png' without full index line
> error: 
> web/pgadmin/browser/server_groups/servers/pgAgent/static/img/pga_job.png:
> patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/steps/static/img/coll-pga_jobstep.png' without
> full index line
> error: web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/coll-pga_jobstep.png: patch does not apply
> error: cannot apply binary patch to 'web/pgadmin/browser/server_
> groups/servers/pgAgent/steps/static/img/pga_jobstep.png' without full
> index line
> error: 
> web/pgadmin/browser/server_groups/servers/pgAgent/steps/static/img/pga_jobstep.png:
> patch does not apply
>
>>
>> I have also attached another patch for miscellaneous fixes, and adding
>> new controls.
>> It includes:
>> - Added DatetimepickerControl, MomentCell (using moment.js)
>> - Used the 'DatetimepickerControl' in Role (Also - resolved an issue,
>> when unset the datetime for 'Valid Until'.)
>> - Added a 'Select All/Unselect All' adaptor for Select2 used by pgAgent
>> nodes.
>> - Fixed an issue with SubNodeCollectionControl, which was not starting
>> the modification session of the child model, when created default value for
>> collection is not null/undefined. And, hence - validation on the child
>> model was not working.
>> - Fixed a memory leak with SqlFieldControl, and SqlTabControl, which was
>> not releasing the CodeMirror properly.
>>
>
> Urgh, that's big.
>
I know.
That's reason - I was reluctant to send earlier.

> Applied - but can you look at the following please?
>
> - Account expires has a hint of 'MMM D  HH:mm:ss.SSS Z". Are
> milliseconds really needed? I also get 00 as a fractional timezone offset.
> Perhaps we should hide that, when it's 00?
>
Changed to '-MM-DD HH:mm:ss Z'.

>
> - The date format differs from the ISO format displayed by the query tool.
> They should be consistent - and really should be either based on the
> client's locale settings, or ISO format.
>
Done

--
Thanks & Regards,

Ashesh Vashi

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


rolvaliduntil_format.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] PATCH: pgAgent support

[Ashesh Vashi]

Will look at them.

On Sep 22, 2016 20:08, "Dave Page" <dp...@pgadmin.org> wrote:

> Hmm - that was clearly hiding from me. I'll take a look now.
>
> Did you see the rest of my comments?
>
> On Thu, Sep 22, 2016 at 3:37 PM, Ashesh Vashi
> <ashesh.va...@enterprisedb.com> wrote:
> > I sent an updated patch immediately.
> >
> >
> > On Sep 22, 2016 20:01, "Dave Page" <dp...@pgadmin.org> wrote:
> >>
> >> Hi
> >>
> >> On Thu, Sep 22, 2016 at 11:47 AM, Ashesh Vashi
> >> <ashesh.va...@enterprisedb.com> wrote:
> >>>
> >>> Hi Dave,
> >>>
> >>> Please find the patch for support for paAgent in pgAdmin 4.
> >>
> >>
> >> Did you forget the binary switch?
> >>
> >> piranha:web dpage$ git apply --binary ~/Downloads/pgagent_v2.patch
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/coll-pga_schedule.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/coll-pga_schedule.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/pga_schedule.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/
> schedules/static/img/pga_schedule.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/coll-pga_job.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/coll-pga_job.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job-disabled.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job-disabled.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/static/
> img/pga_job.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/coll-pga_jobstep.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/coll-pga_jobstep.png:
> >> patch does not apply
> >> error: cannot apply binary patch to
> >> 'web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/pga_jobstep.png'
> >> without full index line
> >> error:
> >> web/pgadmin/browser/server_groups/servers/pgAgent/steps/
> static/img/pga_jobstep.png:
> >> patch does not apply
> >>>
> >>>
> >>> I have also attached another patch for miscellaneous fixes, and adding
> >>> new controls.
> >>> It includes:
> >>> - Added DatetimepickerControl, MomentCell (using moment.js)
> >>> - Used the 'DatetimepickerControl' in Role (Also - resolved an issue,
> >>> when unset the datetime for 'Valid Until'.)
> >>> - Added a 'Select All/Unselect All' adaptor for Select2 used by pgAgent
> >>> nodes.
> >>> - Fixed an issue with SubNodeCollectionControl, which was not starting
> >>> the modification session of the child model, when created default
> value for
> >>> collection is not null/undefined. And, hence - validation on the child
> model
> >>> was not working.
> >>> - Fixed a memory leak with SqlFieldControl, and SqlTabControl, which
> was
> >>> not releasing the CodeMirror properly.
> >>
> >>
> >> Urgh, that's big. Applied - but can you look at the following please?
> >>
> >> - Account expires has a hint of 'MMM D  HH:mm:ss.SSS Z". Are
> >> milliseconds really needed? I also get 00 as a fractional timezone
> offset.
> >> Perhaps we should hide that, when it's 00?
> >>
> >> - The date format differs from the ISO format displayed by the query
> tool.
> >> They should be consistent - and really should be either based on the
> >> client's locale settings, or ISO format.
> >>
> >> 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
>