On Tue, 3 Sept 2024 at 10:51, Yogesh Mahajan < yogesh.maha...@enterprisedb.com> wrote:
> > Thanks, > Yogesh Mahajan > EnterpriseDB > > > > On Tue, Sep 3, 2024 at 3:11 PM Dave Page <dp...@pgadmin.org> wrote: > > Hi > > Hi >> >> On Tue, 3 Sept 2024 at 10:32, Yogesh Mahajan < >> yogesh.maha...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> This isn't the issue in the case of sqlite db while using persistent >>> storage. Issue appears only if external database is used as pgadmin >>> configuration db. Just having different way of persistent storage( in this >>> case backend database) behaviour should not be different. >>> >> >> No, the two database types should behave the same way. Why then, is >> PostgreSQL different from SQLite? Is SQLIte effectively using the --replace >> option whilst PostgreSQL is not (though I can't imagine why that would be >> the case)? >> > > Issue is because the loading server is performed in the absence of the ' > /var/lib/pgadmin/pgadmin4.db' file which is always true in case of an > external database. > Ah, well in that case for PostgreSQL we can just check if the pgAdmin schema has all been created/loaded right? > > However, I retract my previous comment (though if this were new behaviour, >> perhaps I wouldn't) - the docs say: >> >> ===== >> If this file is mapped, server definitions found in it will be loaded at >> launch time. This allows connection information to be pre-loaded into the >> instance of pgAdmin in the container. Note that server definitions are only >> loaded on first launch, i.e. when the configuration database is created, >> and not on subsequent launches using the same configuration database. >> ===== >> >> So the advertised feature is that we do only load the servers once into >> any given configuration database. >> >> >>> >>> Also, on restart admin user specified while container is not recreated. >>> Can't we fix on similar lines? >>> >>> Thanks, >>> Yogesh Mahajan >>> EnterpriseDB >>> >>> >>> On Tue, Sep 3, 2024 at 2:05 PM Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Tue, 3 Sept 2024 at 09:29, Pravesh Sharma < >>>> pravesh.sha...@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Tue, Sep 3, 2024 at 1:47 PM Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Tue, 3 Sept 2024 at 09:10, Pravesh Sharma < >>>>>> pravesh.sha...@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> I am working on issue #7811 >>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/7811>, where using >>>>>>> an external database for storing pgAdmin configuration results in >>>>>>> duplicate >>>>>>> server entries when a container with a mapped servers.json file is >>>>>>> restarted. >>>>>>> >>>>>>> The proposed solution is to implement a check when loading servers. >>>>>>> We would verify the server’s name, host, port, and username to >>>>>>> determine if >>>>>>> the server already exists in the database. If it does, we would skip >>>>>>> registering it again. >>>>>>> >>>>>>> >>>>>>> Please share any suggestions or feedback on this approach. >>>>>>> >>>>>> >>>>>> I would say "Won't fix". If someone is using persistent storage for >>>>>> settings, why launch containers to import the same servers over and over >>>>>> again? Just load them once, manually. >>>>>> >>>>> What if the container needs to be restarted? In that case it will >>>>> again import the server making a duplicate entry. >>>>> >>>> >>>> Not if the servers are manually imported rather than through >>>> servers.json. >>>> >>>> -- >>>> Dave Page >>>> pgAdmin: https://www.pgadmin.org >>>> PostgreSQL: https://www.postgresql.org >>>> EDB: https://www.enterprisedb.com >>>> >>>> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/ >>>> >>>> >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> EDB: https://www.enterprisedb.com >> >> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/ >> >> -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com PGDay UK 2024, 11th September, London: https://2024.pgday.uk/
