Hi, On Tue, Sep 3, 2024 at 3:55 PM Dave Page <dp...@pgadmin.org> wrote:
> > > 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? > Yes, we can try this way. Thanks, Yogesh Mahajan EnterpriseDB > > >> >> 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/ > >
