[pgAdmin4][RM3660] Rename 'SQL Editor' into 'Query Tool' in Preferences
Hi Hackers, Attached is the tiny patch for renaming 'SQL Editor' into 'Query Tool' in Preferences. -- Thanks and Regards, Aditya Toshniwal Software Engineer | EnterpriseDB Software Solutions | Pune "Don't Complain about Heat, Plant a tree" RM3660.patch Description: Binary data
Patch for setting preferences with user id
Hi Hackers, Please find here attached patch for following "modified the function test_utils/set_preference to accommodate user_id." It will help setting preferences in case user_id is other than 1(depending on the user which has been logged in). FYI - the patch is dependent on the patch shared by Murtaza with subject line "[pgAdmin4][Patch]: Code refactoring" -- Thanks, Usman Muzaffar QA Team EnterpriseDB Corporation preferences_v1_code_refactoring.patch Description: Binary data
pgAdmin 4 commit: Save the treeview state periodically, and restore it
Save the treeview state periodically, and restore it automatically when reconnecting. Fixes #1253 Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=528ea88deceacd593fc9e92b083e03f3b849fba9 Author: Khushboo Vashi Modified Files -- docs/en_US/release_notes.rst | 1 + docs/en_US/release_notes_3_5.rst | 18 ++ .../browser/register_browser_preferences.py| 10 + .../browser/server_groups/servers/__init__.py | 3 +- web/pgadmin/browser/static/js/browser.js | 21 +- web/pgadmin/browser/static/js/node.js | 17 +- web/pgadmin/browser/static/js/preferences.js | 3 + web/pgadmin/preferences/static/js/preferences.js | 1 + web/pgadmin/settings/__init__.py | 54 +++- .../static/js/tree/pgadmin_tree_save_state.js | 331 + .../tree/pgadmin_tree_state_save_spec.js | 242 +++ 11 files changed, 680 insertions(+), 21 deletions(-)
Re: [pgAdmin4][Patch]: RM 1253 - Store and reload current location in treeview
Thanks - committed! On Fri, Oct 5, 2018 at 5:24 AM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > Hi Dave, > > I found one issue with the selecting previous selected node which I was > fixed and attached the updated patch. > Please let me know if you find any specific scenario which is not covered. > > While testing the patch, please clear your sqlite entry from the setting > table as we have changed the structure. > > Thanks, > Khushboo > > On Thu, Oct 4, 2018 at 8:07 PM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> >> >> On Thu, Oct 4, 2018 at 7:52 PM Dave Page wrote: >> >>> Hi >>> >>> On Thu, Oct 4, 2018 at 1:12 PM Khushboo Vashi < >>> khushboo.va...@enterprisedb.com> wrote: >>> Hi, Please find the attached updated patch. >>> >>> This seems to behave quite strangely - only sporadically saving the >>> treeview state, and then not always (maybe ever?) restoring the selected >>> node. When I watch the Python console, even with the save interval set to 1 >>> second, I very rarely see the state being saved. For example: >>> >>> 2018-10-04 15:14:01,341: INFO werkzeug: 127.0.0.1 - - [04/Oct/2018 >>> 15:14:01] "GET /browser/database/children/1/1/44243 HTTP/1.1" 200 - >>> 2018-10-04 15:14:01,355: INFO werkzeug: 127.0.0.1 - - [04/Oct/2018 >>> 15:14:01] "POST /settings/save_tree_state/ HTTP/1.1" 200 - >>> 2018-10-04 15:14:02,357: INFO werkzeug: 127.0.0.1 - - [04/Oct/2018 >>> 15:14:02] "POST /settings/save_tree_state/ HTTP/1.1" 200 - >>> 2018-10-04 15:14:23,459: INFO werkzeug: 127.0.0.1 - - [04/Oct/2018 >>> 15:14:23] "GET /preferences/ HTTP/1.1" 200 - >>> >>> You can see there it called it twice, then 21 seconds later I opened the >>> preferences panel to check what the interval was set to (it was still 1 >>> second). Even as I type this some minutes later, it still hasn't called it >>> again. I think it's essential that works reliably, as it's so unreliable to >>> do it on Window close. >>> >>> >> I have checked the previous state and the current state and if both are >> same then I skip the save call. >> Is this the case or even if you change the tree view state it is not >> saving? >> >> >> >>> Thanks, Khushboo On Mon, Oct 1, 2018 at 7:14 PM Dave Page wrote: > Hi > > On Mon, Oct 1, 2018 at 1:53 PM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> Hi Dave >> >> >> On Mon, Oct 1, 2018 at 4:02 PM Dave Page wrote: >> >>> >>> >>> On Mon, Oct 1, 2018 at 11:06 AM Khushboo Vashi < >>> khushboo.va...@enterprisedb.com> wrote: >>> On Tue, Sep 25, 2018 at 6:26 PM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Tue, Sep 25, 2018 at 6:17 PM Dave Page > wrote: > >> >> >> On Tue, Sep 25, 2018 at 3:00 AM Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Tue, Sep 25, 2018 at 12:15 AM Dave Page >>> wrote: >>> Hi On Mon, Sep 24, 2018 at 2:05 AM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > Hi, > > Please find the attached updated patch. > > Feature Details: > - The current tree state as well as the previous will be > stored in the sqlite database. > - The time interval to store the tree state is configurable > via preferences and the default is 30 secs. >-1 can be used to stop the tree saving functionality, > - Jasmine test cases are included. > > Thanks, > Khushboo > This is looking good, however there are a couple of cases where I think it's not quite working as I would expect: 1) As soon as the user opens pgAdmin, the tree state should be restored. As per our initial discussion, we have decided that once the >>> user connects / expands the server, then we will restore that >>> server state. >>> >>> *"If the user has switched network that may cause a whole bunch >>> of connection failures after some period of time. Perhaps we should >>> only >>> restore when opening a particular server." * >>> >> >> Yeah, I remember that now. I guess it just seems less than ideal >> - but I'm not sure how we could open everything by default without >> risking >> connection failures. Let's stick with the original plan (ie. what >> you've >> implemented). >> > Okay. > >> >> >>> >>> 2) If a database or server is disconnected, I would expect it's
pgAdmin 4 commit: Code refactoring:
Code refactoring: - Move the duplicate code for closing the background process dialog into 'test_gui_helper.py', - Simplify the logic by removing the duplicate steps to insert/update binary paths for each server type from 'test_utils.py'. Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0f1651686b28b776265b829e8999e4287d8c3b29 Author: Murtuza Zabuawala Modified Files -- .../pg_utilities_backup_restore_test.py| 27 + .../feature_tests/pg_utilities_maintenance_test.py | 25 +--- .../python_test_utils/test_gui_helper.py | 38 web/regression/python_test_utils/test_utils.py | 67 ++ 4 files changed, 61 insertions(+), 96 deletions(-)
Re: [pgAdmin4][Patch]: Code refactoring
Thanks, patch applied. On Fri, Oct 5, 2018 at 7:56 AM Murtuza Zabuawala < murtuza.zabuaw...@enterprisedb.com> wrote: > +++ > > Below are the changes, > - Move the duplicate code for closing the background process dialog into > 'test_gui_helper.py', > - Simplify the logic by removing the duplicate steps to insert/update > binary paths for each server type from 'test_utils.py'. > > > On Thu, Oct 4, 2018 at 9:35 PM Murtuza Zabuawala < > murtuza.zabuaw...@enterprisedb.com> wrote: > >> Hi, >> >> PFA patch with some code refactoring. >> >> -- >> Regards, >> Murtuza Zabuawala >> EnterpriseDB: 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: [pgAdmin4][Patch]: RM #1513 - Unable to do max selection to drop tables/sequences/functions
Hi
On Fri, Oct 5, 2018 at 12:28 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:
> Hi,
>
> Please find the attached updated patch with the fixes.
>
Whenever I run the python tests, I get the following errors (even after
manually deleting all test tablespaces):
==
ERROR: runTest
(pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_delete_multiple.TableSpaceDeleteTestCase)
Delete Multiple Tablespaces
--
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 59, in create_tablespace
(test_tablespace_name, server['tablespace_path']))
psycopg2.OperationalError: directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_delete_multiple.py",
line 44, in setUp
self.server, self.tablespace_names[1])
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 74, in create_tablespace
raise Exception("Error while creating tablespace. %s" % exception)
Exception: Error while creating tablespace. directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
==
ERROR: runTest
(pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_get.TablespaceGetTestCase)
Check Tablespace Node
--
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 59, in create_tablespace
(test_tablespace_name, server['tablespace_path']))
psycopg2.OperationalError: directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_get.py",
line 36, in setUp
self.server, self.tablespace_name)
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 74, in create_tablespace
raise Exception("Error while creating tablespace. %s" % exception)
Exception: Error while creating tablespace. directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
==
ERROR: runTest
(pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_put.TableSpaceUpdateTestCase)
Check Tablespace Node
--
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 59, in create_tablespace
(test_tablespace_name, server['tablespace_path']))
psycopg2.OperationalError: directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_put.py",
line 36, in setUp
self.server, self.tablespace_name)
File
"/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
line 74, in create_tablespace
raise Exception("Error while creating tablespace. %s" % exception)
Exception: Error while creating tablespace. directory
"/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
tablespace
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pgAdmin 4 commit: Update French translation.
Update French translation. Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=87b64cf3c04498499bdfac9b18cdedd62b2c84ed Author: Fred Escallier Modified Files -- .../translations/fr/LC_MESSAGES/messages.mo| Bin 151664 -> 152102 bytes .../translations/fr/LC_MESSAGES/messages.po| 865 ++--- 2 files changed, 422 insertions(+), 443 deletions(-)
Re: french translation update
Thanks - committed! On Fri, Oct 5, 2018 at 1:33 PM wrote: > hello > based on 3.4 catalog > too late ! > will be for next one > bye > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgAdmin 4 commit: Rename the 'SQL Editor' section of the Preferences to
Rename the 'SQL Editor' section of the Preferences to 'Query Tool' as it applies to the whole tool, not just the editor. Fixes #3660 Branch -- master Details --- https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=26ad6d4c5d43d47999e322f91ff318f052654a5d Author: Aditya Toshniwal Modified Files -- docs/en_US/release_notes_3_5.rst| 2 +- web/pgadmin/tools/sqleditor/__init__.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Re: [pgAdmin4][RM3660] Rename 'SQL Editor' into 'Query Tool' in Preferences
Thanks, applied. On Mon, Oct 8, 2018 at 8:07 AM Aditya Toshniwal < aditya.toshni...@enterprisedb.com> wrote: > Hi Hackers, > > Attached is the tiny patch for renaming 'SQL Editor' into 'Query Tool' in > Preferences. > > -- > Thanks and Regards, > Aditya Toshniwal > Software Engineer | EnterpriseDB Software Solutions | Pune > "Don't Complain about Heat, Plant a tree" > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Patch for setting preferences with user id
Hi On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < usman.muzaf...@enterprisedb.com> wrote: > Hi Hackers, > > Please find here attached patch for following > > "modified the function test_utils/set_preference to accommodate user_id." > > It will help setting preferences in case user_id is other than 1(depending > on the user which has been logged in). > How would that ever happen? When running the tests, we initialise a new settings database, so we're guaranteed that the user ID will be 1. If it isn't, something is wrong. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [pgAdmin4][Patch]: RM #1513 - Unable to do max selection to drop tables/sequences/functions
Hi Dave,
On Mon, Oct 8, 2018 at 3:47 PM Dave Page wrote:
> Hi
> On Fri, Oct 5, 2018 at 12:28 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached updated patch with the fixes.
>>
>
> Whenever I run the python tests, I get the following errors (even after
> manually deleting all test tablespaces):
>
> I am not getting this error. My test cases are passing successfully.
Do you have this issue on particular server or all the server?
Which python version?
> ==
>
> ERROR: runTest
> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_delete_multiple.TableSpaceDeleteTestCase)
>
> Delete Multiple Tablespaces
>
> --
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 59, in create_tablespace
>
> (test_tablespace_name, server['tablespace_path']))
>
> psycopg2.OperationalError: directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_delete_multiple.py",
> line 44, in setUp
>
> self.server, self.tablespace_names[1])
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 74, in create_tablespace
>
> raise Exception("Error while creating tablespace. %s" % exception)
>
> Exception: Error while creating tablespace. directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
>
>
> ==
>
> ERROR: runTest
> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_get.TablespaceGetTestCase)
>
> Check Tablespace Node
>
> --
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 59, in create_tablespace
>
> (test_tablespace_name, server['tablespace_path']))
>
> psycopg2.OperationalError: directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_get.py",
> line 36, in setUp
>
> self.server, self.tablespace_name)
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 74, in create_tablespace
>
> raise Exception("Error while creating tablespace. %s" % exception)
>
> Exception: Error while creating tablespace. directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
>
>
> ==
>
> ERROR: runTest
> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_put.TableSpaceUpdateTestCase)
>
> Check Tablespace Node
>
> --
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 59, in create_tablespace
>
> (test_tablespace_name, server['tablespace_path']))
>
> psycopg2.OperationalError: directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_put.py",
> line 36, in setUp
>
> self.server, self.tablespace_name)
>
> File
> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
> line 74, in create_tablespace
>
> raise Exception("Error while creating tablespace. %s" % exception)
> Exception: Error while creating tablespace. directory
> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
> tablespace
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: > Hi > On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < > usman.muzaf...@enterprisedb.com> wrote: > >> Hi Hackers, >> >> Please find here attached patch for following >> >> "modified the function test_utils/set_preference to accommodate user_id." >> >> It will help setting preferences in case user_id is other than >> 1(depending on the user which has been logged in). >> > > How would that ever happen? When running the tests, we initialise a new > settings database, so we're guaranteed that the user ID will be 1. If it > isn't, something is wrong. > > This is true for pgAdmin but not for PEM. > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 12:55 PM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: > >> Hi >> On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < >> usman.muzaf...@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> Please find here attached patch for following >>> >>> "modified the function test_utils/set_preference to accommodate >>> user_id." >>> >>> It will help setting preferences in case user_id is other than >>> 1(depending on the user which has been logged in). >>> >> >> How would that ever happen? When running the tests, we initialise a new >> settings database, so we're guaranteed that the user ID will be 1. If it >> isn't, something is wrong. >> >> This is true for pgAdmin but not for PEM. > >> And this is the pgAdmin project, not PEM :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: > >> Hi >> On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < >> usman.muzaf...@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> Please find here attached patch for following >>> >>> "modified the function test_utils/set_preference to accommodate >>> user_id." >>> >>> It will help setting preferences in case user_id is other than >>> 1(depending on the user which has been logged in). >>> >> >> How would that ever happen? When running the tests, we initialise a new >> settings database, so we're guaranteed that the user ID will be 1. If it >> isn't, something is wrong. >> >> This is true for pgAdmin but not for PEM. > Currently - feature tests are running as the desktop (runtime) mode. Tomorrow - if we want to enable the feature tests for the server mode, then - this approach could be useful. FYI - I've not yet reviewed the patch though. -- Thanks, Ashesh > -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >
Re: [pgAdmin4][Patch]: RM #1513 - Unable to do max selection to drop tables/sequences/functions
On Mon, Oct 8, 2018 at 12:50 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:
> Hi Dave,
>
> On Mon, Oct 8, 2018 at 3:47 PM Dave Page wrote:
>
>> Hi
>> On Fri, Oct 5, 2018 at 12:28 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the attached updated patch with the fixes.
>>>
>>
>> Whenever I run the python tests, I get the following errors (even after
>> manually deleting all test tablespaces):
>>
>> I am not getting this error. My test cases are passing successfully.
> Do you have this issue on particular server or all the server?
>
I'm just testing on PG10 at the moment (and have run the tests multiple
times).
> Which python version?
>
3.6.6.
>
>
>> ==
>>
>> ERROR: runTest
>> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_delete_multiple.TableSpaceDeleteTestCase)
>>
>> Delete Multiple Tablespaces
>>
>> --
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 59, in create_tablespace
>>
>> (test_tablespace_name, server['tablespace_path']))
>>
>> psycopg2.OperationalError: directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>>
>>
>> During handling of the above exception, another exception occurred:
>>
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_delete_multiple.py",
>> line 44, in setUp
>>
>> self.server, self.tablespace_names[1])
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 74, in create_tablespace
>>
>> raise Exception("Error while creating tablespace. %s" % exception)
>>
>> Exception: Error while creating tablespace. directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>>
>>
>> ==
>>
>> ERROR: runTest
>> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_get.TablespaceGetTestCase)
>>
>> Check Tablespace Node
>>
>> --
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 59, in create_tablespace
>>
>> (test_tablespace_name, server['tablespace_path']))
>>
>> psycopg2.OperationalError: directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>>
>>
>> During handling of the above exception, another exception occurred:
>>
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_get.py",
>> line 36, in setUp
>>
>> self.server, self.tablespace_name)
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 74, in create_tablespace
>>
>> raise Exception("Error while creating tablespace. %s" % exception)
>>
>> Exception: Error while creating tablespace. directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>>
>>
>> ==
>>
>> ERROR: runTest
>> (pgadmin.browser.server_groups.servers.tablespaces.tests.test_tbspc_put.TableSpaceUpdateTestCase)
>>
>> Check Tablespace Node
>>
>> --
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 59, in create_tablespace
>>
>> (test_tablespace_name, server['tablespace_path']))
>>
>> psycopg2.OperationalError: directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>>
>>
>> During handling of the above exception, another exception occurred:
>>
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/test_tbspc_put.py",
>> line 36, in setUp
>>
>> self.server, self.tablespace_name)
>>
>> File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tablespaces/tests/utils.py",
>> line 74, in create_tablespace
>>
>> raise Exception("Error while creating tablespace. %s" % exception)
>> Exception: Error while creating tablespace. directory
>> "/Library/PostgreSQL/tablespaces/10/PG_10_201707211" already in use as a
>> tablespace
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterpr
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi wrote: > On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> >> >> On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: >> >>> Hi >>> On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < >>> usman.muzaf...@enterprisedb.com> wrote: >>> Hi Hackers, Please find here attached patch for following "modified the function test_utils/set_preference to accommodate user_id." It will help setting preferences in case user_id is other than 1(depending on the user which has been logged in). >>> >>> How would that ever happen? When running the tests, we initialise a new >>> settings database, so we're guaranteed that the user ID will be 1. If it >>> isn't, something is wrong. >>> >>> This is true for pgAdmin but not for PEM. >> > Currently - feature tests are running as the desktop (runtime) mode. > Tomorrow - if we want to enable the feature tests for the server mode, > then - this approach could be useful. > The tests can run in either mode. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 5:36 PM Dave Page wrote: > > > On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi > wrote: > >> On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> >>> >>> On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: >>> Hi On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < usman.muzaf...@enterprisedb.com> wrote: > Hi Hackers, > > Please find here attached patch for following > > "modified the function test_utils/set_preference to accommodate > user_id." > > It will help setting preferences in case user_id is other than > 1(depending on the user which has been logged in). > How would that ever happen? When running the tests, we initialise a new settings database, so we're guaranteed that the user ID will be 1. If it isn't, something is wrong. This is true for pgAdmin but not for PEM. >>> >> Currently - feature tests are running as the desktop (runtime) mode. >> Tomorrow - if we want to enable the feature tests for the server mode, >> then - this approach could be useful. >> > > The tests can run in either mode. > No - currently it is running in the runtime mode only. :-) -- Thanks, Ashesh > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 1:08 PM Ashesh Vashi wrote: > On Mon, Oct 8, 2018 at 5:36 PM Dave Page wrote: > >> >> >> On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi < >> ashesh.va...@enterprisedb.com> wrote: >> >>> On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < >>> khushboo.va...@enterprisedb.com> wrote: >>> On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: > Hi > On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < > usman.muzaf...@enterprisedb.com> wrote: > >> Hi Hackers, >> >> Please find here attached patch for following >> >> "modified the function test_utils/set_preference to accommodate >> user_id." >> >> It will help setting preferences in case user_id is other than >> 1(depending on the user which has been logged in). >> > > How would that ever happen? When running the tests, we initialise a > new settings database, so we're guaranteed that the user ID will be 1. If > it isn't, something is wrong. > > This is true for pgAdmin but not for PEM. >>> Currently - feature tests are running as the desktop (runtime) mode. >>> Tomorrow - if we want to enable the feature tests for the server mode, >>> then - this approach could be useful. >>> >> >> The tests can run in either mode. >> > No - currently it is running in the runtime mode only. :-) > We have some tests that *only* run in server mode, such as the password change/recovery tests. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 5:43 PM Dave Page wrote: > > > On Mon, Oct 8, 2018 at 1:08 PM Ashesh Vashi > wrote: > >> On Mon, Oct 8, 2018 at 5:36 PM Dave Page wrote: >> >>> >>> >>> On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi < >>> ashesh.va...@enterprisedb.com> wrote: >>> On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: > >> Hi >> On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < >> usman.muzaf...@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> Please find here attached patch for following >>> >>> "modified the function test_utils/set_preference to accommodate >>> user_id." >>> >>> It will help setting preferences in case user_id is other than >>> 1(depending on the user which has been logged in). >>> >> >> How would that ever happen? When running the tests, we initialise a >> new settings database, so we're guaranteed that the user ID will be 1. If >> it isn't, something is wrong. >> >> This is true for pgAdmin but not for PEM. > Currently - feature tests are running as the desktop (runtime) mode. Tomorrow - if we want to enable the feature tests for the server mode, then - this approach could be useful. >>> >>> The tests can run in either mode. >>> >> No - currently it is running in the runtime mode only. :-) >> > > We have some tests that *only* run in server mode, such as the password > change/recovery tests. > Not the feature tests (only very few API test cases are for the server mode). -- Thanks, Ashesh > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 1:14 PM Ashesh Vashi wrote: > On Mon, Oct 8, 2018 at 5:43 PM Dave Page wrote: > >> >> >> On Mon, Oct 8, 2018 at 1:08 PM Ashesh Vashi < >> ashesh.va...@enterprisedb.com> wrote: >> >>> On Mon, Oct 8, 2018 at 5:36 PM Dave Page wrote: >>> On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi < ashesh.va...@enterprisedb.com> wrote: > On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> >> >> On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: >> >>> Hi >>> On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < >>> usman.muzaf...@enterprisedb.com> wrote: >>> Hi Hackers, Please find here attached patch for following "modified the function test_utils/set_preference to accommodate user_id." It will help setting preferences in case user_id is other than 1(depending on the user which has been logged in). >>> >>> How would that ever happen? When running the tests, we initialise a >>> new settings database, so we're guaranteed that the user ID will be 1. >>> If >>> it isn't, something is wrong. >>> >>> This is true for pgAdmin but not for PEM. >> > Currently - feature tests are running as the desktop (runtime) mode. > Tomorrow - if we want to enable the feature tests for the server mode, > then - this approach could be useful. > The tests can run in either mode. >>> No - currently it is running in the runtime mode only. :-) >>> >> >> We have some tests that *only* run in server mode, such as the password >> change/recovery tests. >> > Not the feature tests (only very few API test cases are for the server > mode). > Most of the test cases will run in server mode (though, yes the feature tests are excluded) - in fact we run 378 Python API tests in that mode against PG10; more with EPAS. However, my point stands; we don't need this patch in pgAdmin to run the tests in server mode. If PEM needs it, then it can go in PEM. We do not add code to pgAdmin unless it benefits pgAdmin. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [pgAdmin4][RM3562] Migrate Bootstrap 3 to Bootstrap 4
Hi, On Mon, Oct 8, 2018 at 4:06 PM Dave Page wrote: > Hi > > On Fri, Oct 5, 2018 at 1:51 PM Aditya Toshniwal < > aditya.toshni...@enterprisedb.com> wrote: > >> Hi Hackers, >> >> Attached is the patch to migrate pgAdmin4 currently based on Bootstrap 3, >> to be Bootstrap 4 compatible. The idea is to move to Bootstrap 4 with >> minimum possible changes in pgAdmin4. I have also used bootstrap scss (and >> not the dist file of bootstrap) to customize bootstrap as per the need of >> pgAdmin4. >> I have done a basic testing. It may not look alike to that with Bootstrap >> 3, but it is possible that you may find some discrepancy (which was proper >> before :P ). Kindly let me know. >> > > Looks good. I spotted a couple of issues though: > > - The menu bar is a different colour now (dark grey rather than black). > Not the end of the world, but I thought I'd mention it. > I thought of keeping the bootstrap default dark color. Will customize it to black. > > - The subnode control has lost some of it's styling. This does need to be > fixed I think. See the attached screenshot ( boostrap 3 is on the left). > Yes. Will send the fix with updated patch. > > Thanks. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Thanks and Regards, Aditya Toshniwal Software Engineer | EnterpriseDB Software Solutions | Pune "Don't Complain about Heat, Plant a tree"
Re: Patch for setting preferences with user id
On Mon, Oct 8, 2018 at 5:53 PM Dave Page wrote: > > > On Mon, Oct 8, 2018 at 1:14 PM Ashesh Vashi > wrote: > >> On Mon, Oct 8, 2018 at 5:43 PM Dave Page wrote: >> >>> >>> >>> On Mon, Oct 8, 2018 at 1:08 PM Ashesh Vashi < >>> ashesh.va...@enterprisedb.com> wrote: >>> On Mon, Oct 8, 2018 at 5:36 PM Dave Page wrote: > > > On Mon, Oct 8, 2018 at 1:00 PM Ashesh Vashi < > ashesh.va...@enterprisedb.com> wrote: > >> On Mon, Oct 8, 2018 at 5:25 PM Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> >>> >>> On Mon, Oct 8, 2018 at 4:18 PM Dave Page wrote: >>> Hi On Mon, Oct 8, 2018 at 9:08 AM Usman Muzaffar < usman.muzaf...@enterprisedb.com> wrote: > Hi Hackers, > > Please find here attached patch for following > > "modified the function test_utils/set_preference to accommodate > user_id." > > It will help setting preferences in case user_id is other than > 1(depending on the user which has been logged in). > How would that ever happen? When running the tests, we initialise a new settings database, so we're guaranteed that the user ID will be 1. If it isn't, something is wrong. This is true for pgAdmin but not for PEM. >>> >> Currently - feature tests are running as the desktop (runtime) mode. >> Tomorrow - if we want to enable the feature tests for the server >> mode, then - this approach could be useful. >> > > The tests can run in either mode. > No - currently it is running in the runtime mode only. :-) >>> >>> We have some tests that *only* run in server mode, such as the password >>> change/recovery tests. >>> >> Not the feature tests (only very few API test cases are for the server >> mode). >> > > Most of the test cases will run in server mode (though, yes the feature > tests are excluded) - in fact we run 378 Python API tests in that mode > against PG10; more with EPAS. However, my point stands; we don't need this > patch in pgAdmin to run the tests in server mode. If PEM needs it, then it > can go in PEM. We do not add code to pgAdmin unless it benefits pgAdmin. > I am not saying whether this is really required for pgAdmin, or not. I am only advocating in what situation it may required. -- Thanks, Ashesh > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[pgAdmin4][Patch]: To fix minor CSS issue
Hi, PFA minor patch to add the required CSS for select2's select-all background color, It is a regression of RM#2927. -- Regards, Murtuza Zabuawala EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company fix_select-all_css.diff Description: Binary data
[pgAdmin4][Patch]: RM #3674 Old session files are not cleared in .pgAdmin session and keep piling up
Hi Hackers Attached is the patch to fix the RM #3674 "Old session files are not cleared in .pgAdmin session and keep piling up". Patch contains following changes: - With current implementation we have override *get_expiration_time*() method of flask and return the expiry time as "datetime.datetime.now() + 1 day (hard coded)". Also the time used as *now*() instead of *utcnow*() which is there in base class method of flask. - *Solution*: We should use *session.permanent *flag and set the *permanent_session_lifetime *variable of app. I have remove the overridden function and set the session.permanent flag to True, and set the permanent_session_lifetime with the specified value in config.py. Added new configuration parameter "SESSION_EXPIRATION_TIME_IN_DAYS". - Added CHECK_SESSION_FILES_INTERVAL configuration parameter in Hour with default value is 24. This is an interval to check the session files for the cleanup. -- *Akshay Joshi* *Sr. Software Architect * *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* RM_3674.patch Description: Binary data
Re: [pgAdmin4][Patch]: RM #3674 Old session files are not cleared in .pgAdmin session and keep piling up
On Mon, Oct 8, 2018 at 6:30 PM Akshay Joshi wrote: > Hi Hackers > > Attached is the patch to fix the RM #3674 "Old session files are not > cleared in .pgAdmin session and keep piling up". Patch contains following > changes: > >- With current implementation we have override *get_expiration_time*() >method of flask and return the expiry time as "datetime.datetime.now() + >1 day (hard coded)". Also the time used as *now*() instead of *utcnow*() >which is there in base class method of flask. > - *Solution*: We should use *session.permanent *flag and set the > *permanent_session_lifetime > *variable of app. I have remove the overridden function and set the > session.permanent flag to True, and set the permanent_session_lifetime > with > the specified value in config.py. Added new configuration parameter > "SESSION_EXPIRATION_TIME_IN_DAYS". >- Added CHECK_SESSION_FILES_INTERVAL configuration parameter in Hour >with default value is 24. This is an interval to check the session files >for the cleanup. > > Can we have this call inside FileBackedSessionManager class? As we have already created the SessionInterface, we should accommodate this into that interface. Also, I would prefer to have the removal check code while opening the session. So, before creating any new session, all the old files (with the threshold we have set in config) should be removed. @ Akshay, When you have proposed the design, I couldn't think of this, so, I have raised my concern now. @ Team, Your thoughts? > -- > *Akshay Joshi* > > *Sr. Software Architect * > > > > *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* >
Re: [pgAdmin4][Patch]: RM #3674 Old session files are not cleared in .pgAdmin session and keep piling up
Hi Khushboo On Tue, Oct 9, 2018 at 9:38 AM Khushboo Vashi wrote: > > > On Mon, Oct 8, 2018 at 6:30 PM Akshay Joshi > wrote: > >> Hi Hackers >> >> Attached is the patch to fix the RM #3674 "Old session files are not >> cleared in .pgAdmin session and keep piling up". Patch contains >> following changes: >> >>- With current implementation we have override *get_expiration_time*() >>method of flask and return the expiry time as "datetime.datetime.now() + >>1 day (hard coded)". Also the time used as *now*() instead of *utcnow*() >>which is there in base class method of flask. >> - *Solution*: We should use *session.permanent *flag and set the >> *permanent_session_lifetime >> *variable of app. I have remove the overridden function and set >> the session.permanent flag to True, and set the >> permanent_session_lifetime >> with the specified value in config.py. Added new configuration >> parameter "SESSION_EXPIRATION_TIME_IN_DAYS". >>- Added CHECK_SESSION_FILES_INTERVAL configuration parameter in Hour >>with default value is 24. This is an interval to check the session files >>for the cleanup. >> >> Can we have this call inside FileBackedSessionManager class? As we have > already created the SessionInterface, we should accommodate this into that > interface. Also, I would prefer to have the removal check code while > opening the session. So, before creating any new session, all the old files > (with the threshold we have set in config) should be removed. > Yesterday we sit together and try to do that as we have created cleanup_session_files() function in FileBackedSessionManager class and from cleanup function of "misc/__init__.py" we will have to call that function like "current_app.sesstion_interface.manager.parent.clean_session_files()" and this doesn't look good as we discussed. Regarding deleting the old file before creating any new session will be an overhead to iterate over the sessions folder check the last modified time of each file and compare that for cleanup, so with my patch that time is configurable and by default it is 24 hours. > > @ Akshay, > When you have proposed the design, I couldn't think of this, so, I have > raised my concern now. > > @ Team, > Your thoughts? > > >> -- >> *Akshay Joshi* >> >> *Sr. Software Architect * >> >> >> >> *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* >> > -- *Akshay Joshi* *Sr. Software Architect * *Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
