Re: Require suggestions on issue #7811

On Tue, 3 Sept 2024 at 10:51, Yogesh Mahajan <
yogesh(dot)mahajan(at)enterprisedb(dot)com> wrote:

>
> Thanks,
> Yogesh Mahajan
> EnterpriseDB
>
>
>
> On Tue, Sep 3, 2024 at 3:11 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> Hi
>
> Hi
>>
>> On Tue, 3 Sept 2024 at 10:32, Yogesh Mahajan <
>> yogesh(dot)mahajan(at)enterprisedb(dot)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 <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, 3 Sept 2024 at 09:29, Pravesh Sharma <
>>>> pravesh(dot)sharma(at)enterprisedb(dot)com> wrote:
>>>>
>>>>> Hi Dave,
>>>>>
>>>>> On Tue, Sep 3, 2024 at 1:47 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Tue, 3 Sept 2024 at 09:10, Pravesh Sharma <
>>>>>> pravesh(dot)sharma(at)enterprisedb(dot)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/