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