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