Hi hackers, We've reviewed this patch and it need us changing our own config_local.py file. It's ok and we'll do the change in our configuration.
Thanks, Bing & Violet On Wed, Aug 9, 2017 at 8:49 PM, Surinder Kumar < surinder.ku...@enterprisedb.com> wrote: > Hi > > This patch includes the fix where this patch breaks when feature tests are > run. > > Set builtins.SERVER_MODE if it is present in globals()['SERVER_MODE'] > else set to None. > > Please find updated patch. > Thanks, > Surinder > > > On Wed, Aug 9, 2017 at 11:57 AM, Surinder Kumar < > surinder.ku...@enterprisedb.com> wrote: > >> Sure, I will update. >> >> On Wed, Aug 9, 2017 at 11:17 AM, Dave Page <dp...@pgadmin.org> wrote: >> >>> Please update the patch :-) >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK:http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >>> On 9 Aug 2017, at 05:53, Surinder Kumar <surinder.ku...@enterprisedb.com> >>> wrote: >>> >>> Hi, >>> >>> I noticed that test cases don’t run and I got an error: >>> >>> (pgAdmin_27)Laptop195:regression surinder$ python runtests.py --pkg >>> feature_tests >>> <module '__builtin__' (built-in)> >>> Traceback (most recent call last): >>> File "runtests.py", line 45, in <module> >>> import config >>> File "/Users/surinder/Documents/Projects/pgadmin4/web/config.py", line >>> 121, in <module> >>> if builtins.SERVER_MODE is None: >>> AttributeError: 'module' object has no attribute' >>> SERVER_MODE >>> ' >>> >>> I think this is because we are setting first builtins.SERVER_MODE in >>> pgAdmin4.py >>> but in test cases pgAdmin4.py is not being called. >>> >>> >>> On Tue, Aug 8, 2017 at 4:03 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Tue, Aug 8, 2017 at 11:27 AM, Surinder Kumar < >>>> surinder.ku...@enterprisedb.com> wrote: >>>> >>>>> On Tue, Aug 8, 2017 at 1:47 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>> >>>>>> >>>>>> On Tue, Aug 8, 2017 at 7:18 AM, Surinder Kumar < >>>>>> surinder.ku...@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Ubuntu-14.04, I got error Application Server couldn't be >>>>>>> contacted: >>>>>>> >>>>>>> *Steps performed:* >>>>>>> >>>>>>> - I have already installed pgAdmin4-1.4 which come with >>>>>>> PostgreSQL-9.6 installer. >>>>>>> then I run root@ubuntu:/opt/PostgreSQL/9.6/pgAdmin 4/bin# >>>>>>> ./pgAdmin4./. >>>>>>> - Now took latest git pull from HEAD >>>>>>> - Apply unified_config.diff patch. >>>>>>> - Then compiled pgAdmin4 in runtime and then run ./pgAdmin. >>>>>>> - Got error Application Server couldn't be contacted. >>>>>>> >>>>>>> But when I ran ./pgAdmin4 for the second time. pgAdmin4 runs >>>>>>> without any issue. >>>>>>> I didn’t get any error on the terminal and log file. >>>>>>> I couldn't find why it gives this error. >>>>>>> >>>>>> >>>>>> I know Fahar has run into this with existing releases on Ubuntu. If >>>>>> you enable debugging, can you see any clues? I assume it's going round >>>>>> the >>>>>> retry loop before aborting? >>>>>> >>>>>>> *Another issue related to Alembic:* >>>>>>> >>>>>>> If I am running pgAdmin4 already installed on my machine, then I >>>>>>> upgrade pgAdmin4 using Python wheel: >>>>>>> >>>>>>> (test_p27) surinder@ubuntu:~/virtualenvs/test_p27$ python >>>>>>> ~/virtualenvs/test_p27/lib/python2.7/site-packages/pgadmin4/ >>>>>>> pgAdmin4.py >>>>>>> >>>>>>> *I am getting error:* >>>>>>> >>>>>>> alembic.util.exc.CommandError: Can't locate revision identified by >>>>>>> 'd85a62333272' >>>>>>> >>>>>>> To fix this, I have to delete existing pgadmin4.db file. I don’t >>>>>>> know if it is a valid case or should I log an RM if it is? >>>>>>> >>>>>> That's an annoying side-effect of the move to Alembic. The previous >>>>>> DB code would quite happily (and intentionally) run with a newer version >>>>>> of >>>>>> the database, however, the new code does not. You'll see this issue >>>>>> whenever you've run a newer version of pgAdmin and then go back to an >>>>>> older >>>>>> version that uses an older schema version. >>>>>> >>>>>> It would be nice to change this so it doesn't complain - but we'd >>>>>> have to be cautious to only break compatibility on major releases. >>>>>> >>>>>> >>>>>> >>>>>>> Apart for this, I didn’t see any functionality break. It works!! >>>>>>> >>>>>>> >>>>>>> I liked the approach to set SEVER_MODE in runtime using built-ins. >>>>>>> >>>>>> Thanks. Do you think it warrants a 2.0 version number, given the >>>>>> potential for breaking existing installations (I do, but would like other >>>>>> feedback)? If we do that - and thus allow a parallel installation of 1.x >>>>>> and 2.x), how would we resolve the Alembic issue you noted such that both >>>>>> versions could be run against the same DB? >>>>>> >>>>> To resolve this issue while upgrading to newer version of pgAdmin4, we >>>>> can add a parameter version_table: 'alembic_version-1.6 in >>>>> web/migrations/env.py of upcoming pgAdmin4 source code(reference link >>>>> <https://issues.asterisk.org/jira/secure/attachment/51610/ASTERISK-24311-set-version-table.diff> >>>>> ) >>>>> It will create a new version table in pgadmin4.db database and it >>>>> will instruct the Alembic to run migrations for the version stored in >>>>> table(alembic_version-1.6) when new pgAdmin4 will be installed. >>>>> >>>>> I tried to check if it works or not. But somehow I couldn’t install >>>>> pgAdmin4-1.5 from wheel. >>>>> >>>>> Alternatively I will try to generate new schema using in pgAdmin4 >>>>> source code(Git HEAD). It will generate a new migration version and then i >>>>> will run pgAdmin4-1.6 from wheel having different migration number. It >>>>> will >>>>> create pgadmin4.db for 1.5. >>>>> Then >>>>> I will run pgAdmin4-1.6 from source code, so migration will take >>>>> place and hopefully >>>>> the >>>>> sa >>>>> me >>>>> >>>>> pgadmin4.db will work for newer pgAdmin4 version. >>>>> >>>>> Reference link >>>>> <https://issues.asterisk.org/jira/browse/ASTERISK-24311> where the >>>>> same issue has been discussed. >>>>> >>>> >>>> Sounds good - please investigate further. >>>> >>> I spent some time, understands how Alembic works and I thought it is >>> easy using the reference link but not, It needs more R&D. I will look how >>> can we fix it. >>> >>>> >>>> Thanks! >>>> >>>> >>>>> Thanks, >>>>> Surinder >>>>> >>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Surinder >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 7, 2017 at 7:01 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 7, 2017 at 1:43 PM, Surinder Kumar < >>>>>>>> surinder.ku...@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The patch seems to work in Runtime mode, but fails in Server mode >>>>>>>>> with error: >>>>>>>>> >>>>>>>>> (pgAdmin_27)Laptop195:pgadmin4 surinder$ python web/pgAdmin4.py >>>>>>>>> Traceback (most recent call last): >>>>>>>>> File "web/pgAdmin4.py", line 55, in <module> >>>>>>>>> exec(open(file_quote(setupfile), 'r').read()) >>>>>>>>> File "<string>", line 35, in <module> >>>>>>>>> File >>>>>>>>> "/Users/surinder/Documents/Projects/pgadmin4/web/pgadmin/setup/data_directory.py", >>>>>>>>> line 23, in create_app_data_directory >>>>>>>>> >>>>>>>>> _create_directory_if_not_exists(os.path.dirname(config.SQLITE_PATH)) >>>>>>>>> File >>>>>>>>> "/Users/surinder/Documents/Projects/pgadmin4/web/pgadmin/setup/data_directory.py", >>>>>>>>> line 15, in _create_directory_if_not_exists >>>>>>>>> os.mkdir(_path) >>>>>>>>> OSError: [Errno 13] Permission denied: '/var/lib/pgadmin' >>>>>>>>> (pgAdmin_27)Laptop195:pgadmin4 surinder$ >>>>>>>>> >>>>>>>>> This is because the directory /var/lib/ has root only access and >>>>>>>>> I am running pgAdmin4 with the non-root user. >>>>>>>>> >>>>>>>>> Also pgadmin directory is not created. >>>>>>>>> >>>>>>>>> (pgAdmin_35)Laptop195:pgadmin4 surinder$ ls /var/lib/pgadmin >>>>>>>>> ls: /var/lib/pgadmin: No such file or directory >>>>>>>>> >>>>>>>>> I got same error with MacOSX and Ubuntu-14.04 machines >>>>>>>>> irrespective of Python version. >>>>>>>>> >>>>>>>>> Meanwhile, I am testing patch with other test cases. >>>>>>>>> >>>>>>>> That's fully expected. In the case of Linux, the packages will be >>>>>>>> responsible for creating those directories with the appropriate >>>>>>>> ownership. >>>>>>>> In other cases, the user would. >>>>>>>> >>>>>>> ok, I got it. >>>>>>> >>>>>>>> >>>>>>>> There's not really much we can do about that - and it's exactly >>>>>>>> what would happen if you try to run many other packages yourself when >>>>>>>> standard *nix paths are used. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Surinder >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 7, 2017 at 4:33 PM, Surinder Kumar < >>>>>>>>> surinder.ku...@enterprisedb.com> wrote: >>>>>>>>> >>>>>>>>>> On Mon, Aug 7, 2017 at 4:11 PM, Ashesh Vashi < >>>>>>>>>> ashesh.va...@enterprisedb.com> wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, Aug 7, 2017 at 3:59 PM, Dave Page <dp...@pgadmin.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Anyone? >>>>>>>>>>>> >>>>>>>>>>> Surinder - please give this one priority. >>>>>>>>>>> >>>>>>>>>> Sure >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> 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, Jul 20, 2017 at 5:03 PM, Dave Page <dp...@pgadmin.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> All, >>>>>>>>>>>>> >>>>>>>>>>>>> Attached is a patch that aims to allow us to have a >>>>>>>>>>>>> standardised config that will work out of the box for both web >>>>>>>>>>>>> and desktop >>>>>>>>>>>>> modes. It does this by doing two things: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) The runtime sets SERVER_MODE in the Python environment >>>>>>>>>>>>> before starting the app. If this value is set, then it overrides >>>>>>>>>>>>> the >>>>>>>>>>>>> default value of SERVER_MODE in the config. >>>>>>>>>>>>> >>>>>>>>>>>>> 2) The config file then offers default values for the various >>>>>>>>>>>>> file locations for both server and desktop mode, setting them >>>>>>>>>>>>> appropriately >>>>>>>>>>>>> based on the derived SERVER_MODE value. >>>>>>>>>>>>> >>>>>>>>>>>>> The only downsides I can see from this are: >>>>>>>>>>>>> >>>>>>>>>>>>> - You cannot run in server mode in the runtime without >>>>>>>>>>>>> manually reconfiguring SERVER_MODE and likely a bunch of paths in >>>>>>>>>>>>> config_local.py >>>>>>>>>>>>> >>>>>>>>>>>>> - If you want to override SERVER_MODE, you'll probably also >>>>>>>>>>>>> need to redefine the various paths in config_local.py. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see either being something 99.9% of users would need >>>>>>>>>>>>> though. >>>>>>>>>>>>> >>>>>>>>>>>>> Can anyone see if the patch breaks anything, or if I missed >>>>>>>>>>>>> any side effects? >>>>>>>>>>>>> >>>>>>>>>>>>> Is it likely to break things during upgrades? I suspect so... >>>>>>>>>>>>> so maybe this should prompt v2.0? >>>>>>>>>>>>> >>>>>>>>>>>>> I'd appreciate multiple reviews of this, as it could break >>>>>>>>>>>>> things. Note that I haven't yet updated the docs. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: http://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EnterpriseDB UK: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>> >>> >> >
