public inbox for [email protected]
help / color / mirror / Atom feedRegarding feature #3319
24+ messages / 5 participants
[nested] [flat]
* Regarding feature #3319
@ 2024-08-12 05:50 Anil Sahoo <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Anil Sahoo @ 2024-08-12 05:50 UTC (permalink / raw)
To: pgadmin-hackers
Hi Hackers,
This feature #3319 <https://github.com/pgadmin-org/pgadmin4/issues/3319;,
demands the Workspace and the Query tool panel to be saved before exiting
the application and on restart it will show earlier opened panels.
We are already saving the Browser layout, Query tool layout and the Object
explorer tree state but to save the contents of panels we will initially
start with the Query tool. The below implementation will be done,
1. Store the query tool panels and the list of connections present in
each query tool panel and the active connection
2. Store the query that is written in the editor
3. Store the contents of scratch pad
We will use debouncing to store the workspace data and all other data
related to panels in the pgAdmin 4's configured database file. Through
debouncing we will be able to call the API at certain intervals of user
interaction, and it will update the stored data related to workspace and
all other panels.
Kindly share your inputs/suggestions.
Thanks
Anil
--
<http://www.enterprisedb.com;
*Anil Sahoo*
Software Engineer
www.enterprisedb.com
Power to Postgres
<https://www.linkedin.com/company/edbpostgres;
<https://twitter.com/edbpostgres?lang=en;
<https://www.facebook.com/EDBpostgres;
<https://www.instagram.com/EDBpostgres/;
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-12 08:38 Dave Page <[email protected]>
parent: Anil Sahoo <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2024-08-12 08:38 UTC (permalink / raw)
To: Anil Sahoo <[email protected]>; +Cc: pgadmin-hackers
Hi
On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
wrote:
> Hi Hackers,
>
>
> This feature #3319 <https://github.com/pgadmin-org/pgadmin4/issues/3319;,
> demands the Workspace and the Query tool panel to be saved before exiting
> the application and on restart it will show earlier opened panels.
>
>
> We are already saving the Browser layout, Query tool layout and the Object
> explorer tree state but to save the contents of panels we will initially
> start with the Query tool. The below implementation will be done,
>
> 1. Store the query tool panels and the list of connections present in
> each query tool panel and the active connection
> 2. Store the query that is written in the editor
> 3. Store the contents of scratch pad
>
> The main reason that this has never been worked on is that there is no way
to restore the state of a connection to what it was and be sure we've got
it right. How do you propose to handle that? I assume in a similar way to
the warnings we give if a connection has to be re-established?
>
>
>
> We will use debouncing to store the workspace data and all other data
> related to panels in the pgAdmin 4's configured database file. Through
> debouncing we will be able to call the API at certain intervals of user
> interaction, and it will update the stored data related to workspace and
> all other panels.
>
OK.
--
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/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-12 09:31 Anil Sahoo <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Anil Sahoo @ 2024-08-12 09:31 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
Hi,
Yes, We will store the details that are needed to re-establish the
connection.
Regards
Anil
--
<http://www.enterprisedb.com;
*Anil Sahoo*
Software Engineer
www.enterprisedb.com
Power to Postgres
<https://www.linkedin.com/company/edbpostgres;
<https://twitter.com/edbpostgres?lang=en;
<https://www.facebook.com/EDBpostgres;
<https://www.instagram.com/EDBpostgres/;
On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
> Hi
>
> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
> wrote:
>
>> Hi Hackers,
>>
>>
>> This feature #3319 <https://github.com/pgadmin-org/pgadmin4/issues/3319;,
>> demands the Workspace and the Query tool panel to be saved before exiting
>> the application and on restart it will show earlier opened panels.
>>
>>
>> We are already saving the Browser layout, Query tool layout and the
>> Object explorer tree state but to save the contents of panels we will
>> initially start with the Query tool. The below implementation will be done,
>>
>> 1. Store the query tool panels and the list of connections present in
>> each query tool panel and the active connection
>> 2. Store the query that is written in the editor
>> 3. Store the contents of scratch pad
>>
>> The main reason that this has never been worked on is that there is no
> way to restore the state of a connection to what it was and be sure we've
> got it right. How do you propose to handle that? I assume in a similar way
> to the warnings we give if a connection has to be re-established?
>
>>
>>
>>
>> We will use debouncing to store the workspace data and all other data
>> related to panels in the pgAdmin 4's configured database file. Through
>> debouncing we will be able to call the API at certain intervals of user
>> interaction, and it will update the stored data related to workspace and
>> all other panels.
>>
>
> OK.
>
> --
> 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/
>
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-19 06:09 Aditya Toshniwal <[email protected]>
parent: Anil Sahoo <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Aditya Toshniwal @ 2024-08-19 06:09 UTC (permalink / raw)
To: Anil Sahoo <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers
Hi Anil,
On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <[email protected]>
wrote:
> Hi,
>
> Yes, We will store the details that are needed to re-establish the
> connection.
>
How/Where are you planning to store the information? Query text could be
large.
>
> Regards
> Anil
> --
>
> <http://www.enterprisedb.com;
>
> *Anil Sahoo*
>
> Software Engineer
>
> www.enterprisedb.com
>
> Power to Postgres
>
> <https://www.linkedin.com/company/edbpostgres;
> <https://twitter.com/edbpostgres?lang=en;
> <https://www.facebook.com/EDBpostgres;
> <https://www.instagram.com/EDBpostgres/;
>
>
> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>
>> Hi
>>
>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
>> wrote:
>>
>>> Hi Hackers,
>>>
>>>
>>> This feature #3319 <https://github.com/pgadmin-org/pgadmin4/issues/3319;,
>>> demands the Workspace and the Query tool panel to be saved before exiting
>>> the application and on restart it will show earlier opened panels.
>>>
>>>
>>> We are already saving the Browser layout, Query tool layout and the
>>> Object explorer tree state but to save the contents of panels we will
>>> initially start with the Query tool. The below implementation will be done,
>>>
>>> 1. Store the query tool panels and the list of connections present
>>> in each query tool panel and the active connection
>>> 2. Store the query that is written in the editor
>>> 3. Store the contents of scratch pad
>>>
>>> The main reason that this has never been worked on is that there is no
>> way to restore the state of a connection to what it was and be sure we've
>> got it right. How do you propose to handle that? I assume in a similar way
>> to the warnings we give if a connection has to be re-established?
>>
>>>
>>>
>>>
>>> We will use debouncing to store the workspace data and all other data
>>> related to panels in the pgAdmin 4's configured database file. Through
>>> debouncing we will be able to call the API at certain intervals of user
>>> interaction, and it will update the stored data related to workspace and
>>> all other panels.
>>>
>>
>> OK.
>>
>> --
>> 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/
>>
>>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-20 03:40 Anil Sahoo <[email protected]>
parent: Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Anil Sahoo @ 2024-08-20 03:40 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers
Hi Aditya,
As we are already storing the query history in the pgAdmin 4's database
file.
I am planning to store the information the same way. That can be an
internal database file like SQLite or external database.
Let me know if you all have any suggestions on this.
Thanks
Anil
--
<http://www.enterprisedb.com;
*Anil Sahoo*
Software Engineer
www.enterprisedb.com
Power to Postgres
<https://www.linkedin.com/company/edbpostgres;
<https://twitter.com/edbpostgres?lang=en;
<https://www.facebook.com/EDBpostgres;
<https://www.instagram.com/EDBpostgres/;
On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
[email protected]> wrote:
> Hi Anil,
>
> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <[email protected]>
> wrote:
>
>> Hi,
>>
>> Yes, We will store the details that are needed to re-establish the
>> connection.
>>
>
> How/Where are you planning to store the information? Query text could be
> large.
>
>>
>> Regards
>> Anil
>> --
>>
>> <http://www.enterprisedb.com;
>>
>> *Anil Sahoo*
>>
>> Software Engineer
>>
>> www.enterprisedb.com
>>
>> Power to Postgres
>>
>> <https://www.linkedin.com/company/edbpostgres;
>> <https://twitter.com/edbpostgres?lang=en;
>> <https://www.facebook.com/EDBpostgres;
>> <https://www.instagram.com/EDBpostgres/;
>>
>>
>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>
>>> Hi
>>>
>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
>>> wrote:
>>>
>>>> Hi Hackers,
>>>>
>>>>
>>>> This feature #3319
>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>> Workspace and the Query tool panel to be saved before exiting the
>>>> application and on restart it will show earlier opened panels.
>>>>
>>>>
>>>> We are already saving the Browser layout, Query tool layout and the
>>>> Object explorer tree state but to save the contents of panels we will
>>>> initially start with the Query tool. The below implementation will be done,
>>>>
>>>> 1. Store the query tool panels and the list of connections present
>>>> in each query tool panel and the active connection
>>>> 2. Store the query that is written in the editor
>>>> 3. Store the contents of scratch pad
>>>>
>>>> The main reason that this has never been worked on is that there is no
>>> way to restore the state of a connection to what it was and be sure we've
>>> got it right. How do you propose to handle that? I assume in a similar way
>>> to the warnings we give if a connection has to be re-established?
>>>
>>>>
>>>>
>>>>
>>>> We will use debouncing to store the workspace data and all other data
>>>> related to panels in the pgAdmin 4's configured database file. Through
>>>> debouncing we will be able to call the API at certain intervals of user
>>>> interaction, and it will update the stored data related to workspace and
>>>> all other panels.
>>>>
>>>
>>> OK.
>>>
>>> --
>>> 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/
>>>
>>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
> <https://www.enterprisedb.com/;
> "Don't Complain about Heat, Plant a TREE"
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-20 04:44 Aditya Toshniwal <[email protected]>
parent: Anil Sahoo <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Aditya Toshniwal @ 2024-08-20 04:44 UTC (permalink / raw)
To: Anil Sahoo <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers
Hi Anil,
There can be multiple query tools open with large files. Not entirely sure
if storing in SQLite DB is a good idea.
External databases won't come in the picture as 99.99% users will not use
external DB for desktop app. We're only doing this for desktop app.
And also consider the case where a SQL file is opened with some unsaved
changes.
On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
wrote:
> Hi Aditya,
>
> As we are already storing the query history in the pgAdmin 4's database
> file.
> I am planning to store the information the same way. That can be an
> internal database file like SQLite or external database.
>
> Let me know if you all have any suggestions on this.
>
> Thanks
> Anil
> --
>
> <http://www.enterprisedb.com;
>
> *Anil Sahoo*
>
> Software Engineer
>
> www.enterprisedb.com
>
> Power to Postgres
>
> <https://www.linkedin.com/company/edbpostgres;
> <https://twitter.com/edbpostgres?lang=en;
> <https://www.facebook.com/EDBpostgres;
> <https://www.instagram.com/EDBpostgres/;
>
>
> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
> [email protected]> wrote:
>
>> Hi Anil,
>>
>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> Yes, We will store the details that are needed to re-establish the
>>> connection.
>>>
>>
>> How/Where are you planning to store the information? Query text could be
>> large.
>>
>>>
>>> Regards
>>> Anil
>>> --
>>>
>>> <http://www.enterprisedb.com;
>>>
>>> *Anil Sahoo*
>>>
>>> Software Engineer
>>>
>>> www.enterprisedb.com
>>>
>>> Power to Postgres
>>>
>>> <https://www.linkedin.com/company/edbpostgres;
>>> <https://twitter.com/edbpostgres?lang=en;
>>> <https://www.facebook.com/EDBpostgres;
>>> <https://www.instagram.com/EDBpostgres/;
>>>
>>>
>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>
>>>> Hi
>>>>
>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Hackers,
>>>>>
>>>>>
>>>>> This feature #3319
>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>>> Workspace and the Query tool panel to be saved before exiting the
>>>>> application and on restart it will show earlier opened panels.
>>>>>
>>>>>
>>>>> We are already saving the Browser layout, Query tool layout and the
>>>>> Object explorer tree state but to save the contents of panels we will
>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>
>>>>> 1. Store the query tool panels and the list of connections present
>>>>> in each query tool panel and the active connection
>>>>> 2. Store the query that is written in the editor
>>>>> 3. Store the contents of scratch pad
>>>>>
>>>>> The main reason that this has never been worked on is that there is no
>>>> way to restore the state of a connection to what it was and be sure we've
>>>> got it right. How do you propose to handle that? I assume in a similar way
>>>> to the warnings we give if a connection has to be re-established?
>>>>
>>>>>
>>>>>
>>>>>
>>>>> We will use debouncing to store the workspace data and all other data
>>>>> related to panels in the pgAdmin 4's configured database file. Through
>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>> interaction, and it will update the stored data related to workspace and
>>>>> all other panels.
>>>>>
>>>>
>>>> OK.
>>>>
>>>> --
>>>> 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/
>>>>
>>>>
>>
>> --
>> Thanks,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>> <https://www.enterprisedb.com/;
>> "Don't Complain about Heat, Plant a TREE"
>>
>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2024-08-28 07:19 Anil Sahoo <[email protected]>
parent: Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Anil Sahoo @ 2024-08-28 07:19 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers
Hi Hackers,
We are going to store the below details
1. List of Query tools opened
2. List of connections present in each query tool
3. Each connection’s details that are required to make the connection
once the application restarts
4. Active connection details of each query tool opened
5. Store the query that is written in the editor that may or may not be
executed
6. Store the contents of the scratch pad
7. Store the file which is opened in the query tool with any unsaved
changes
Some questions that I have are mentioned below,
1. For desktop mode the application is opened with some query tools and
the user closes the application and on restarts the tabs will open as it is
and will restore the workspace and connections on query tool tabs. But for
server mode do we need to restore the query tool tabs and workspace?
Because we see most of the desktop applications have this feature.
2. I came across one issue reported by one user i.e
https://github.com/pgadmin-org/pgadmin4/issues/6666, where pgAdmin
crashed due to long SQL scripts that can be in Megabytes stored as query
history. We fixed it by giving MAX_QUERY_LENGTH to 1000000, and
checking if any query length is below the value then it gets stored in the
database as query history else not. Should we go with storing the workspace
and query tool details in SQLite DB or use a file system to store the
details and retrieve the content accordingly?
Please let me know your suggestions on this.
Thanks
Anil
--
<http://www.enterprisedb.com;
*Anil Sahoo*
Software Engineer
www.enterprisedb.com
Power to Postgres
<https://www.linkedin.com/company/edbpostgres;
<https://twitter.com/edbpostgres?lang=en;
<https://www.facebook.com/EDBpostgres;
<https://www.instagram.com/EDBpostgres/;
On Tue, Aug 20, 2024 at 10:14 AM Aditya Toshniwal <
[email protected]> wrote:
> Hi Anil,
>
> There can be multiple query tools open with large files. Not entirely sure
> if storing in SQLite DB is a good idea.
> External databases won't come in the picture as 99.99% users will not use
> external DB for desktop app. We're only doing this for desktop app.
> And also consider the case where a SQL file is opened with some unsaved
> changes.
>
> On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
> wrote:
>
>> Hi Aditya,
>>
>> As we are already storing the query history in the pgAdmin 4's database
>> file.
>> I am planning to store the information the same way. That can be an
>> internal database file like SQLite or external database.
>>
>> Let me know if you all have any suggestions on this.
>>
>> Thanks
>> Anil
>> --
>>
>> <http://www.enterprisedb.com;
>>
>> *Anil Sahoo*
>>
>> Software Engineer
>>
>> www.enterprisedb.com
>>
>> Power to Postgres
>>
>> <https://www.linkedin.com/company/edbpostgres;
>> <https://twitter.com/edbpostgres?lang=en;
>> <https://www.facebook.com/EDBpostgres;
>> <https://www.instagram.com/EDBpostgres/;
>>
>>
>> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Anil,
>>>
>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Yes, We will store the details that are needed to re-establish the
>>>> connection.
>>>>
>>>
>>> How/Where are you planning to store the information? Query text could be
>>> large.
>>>
>>>>
>>>> Regards
>>>> Anil
>>>> --
>>>>
>>>> <http://www.enterprisedb.com;
>>>>
>>>> *Anil Sahoo*
>>>>
>>>> Software Engineer
>>>>
>>>> www.enterprisedb.com
>>>>
>>>> Power to Postgres
>>>>
>>>> <https://www.linkedin.com/company/edbpostgres;
>>>> <https://twitter.com/edbpostgres?lang=en;
>>>> <https://www.facebook.com/EDBpostgres;
>>>> <https://www.instagram.com/EDBpostgres/;
>>>>
>>>>
>>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Hackers,
>>>>>>
>>>>>>
>>>>>> This feature #3319
>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>>>> Workspace and the Query tool panel to be saved before exiting the
>>>>>> application and on restart it will show earlier opened panels.
>>>>>>
>>>>>>
>>>>>> We are already saving the Browser layout, Query tool layout and the
>>>>>> Object explorer tree state but to save the contents of panels we will
>>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>>
>>>>>> 1. Store the query tool panels and the list of connections
>>>>>> present in each query tool panel and the active connection
>>>>>> 2. Store the query that is written in the editor
>>>>>> 3. Store the contents of scratch pad
>>>>>>
>>>>>> The main reason that this has never been worked on is that there is
>>>>> no way to restore the state of a connection to what it was and be sure
>>>>> we've got it right. How do you propose to handle that? I assume in a
>>>>> similar way to the warnings we give if a connection has to be
>>>>> re-established?
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We will use debouncing to store the workspace data and all other data
>>>>>> related to panels in the pgAdmin 4's configured database file. Through
>>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>>> interaction, and it will update the stored data related to workspace and
>>>>>> all other panels.
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>> --
>>>>> 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/
>>>>>
>>>>>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>> <https://www.enterprisedb.com/;
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
> <https://www.enterprisedb.com/;
> "Don't Complain about Heat, Plant a TREE"
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-01-16 06:37 Aditya Toshniwal <[email protected]>
parent: Anil Sahoo <[email protected]>
0 siblings, 2 replies; 24+ messages in thread
From: Aditya Toshniwal @ 2025-01-16 06:37 UTC (permalink / raw)
To: Anil Sahoo <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers
Hi Anil/Dave,
Why not use browser localStorage for saving this information? It persists
when the browser closes and is based on the URL. It is safer to store at
the user's machine than on our server.
For Electron also it should work.
This will reduce load on the pgAdmin server.
On Wed, Aug 28, 2024 at 12:50 PM Anil Sahoo <[email protected]>
wrote:
> Hi Hackers,
>
>
> We are going to store the below details
>
> 1. List of Query tools opened
> 2. List of connections present in each query tool
> 3. Each connection’s details that are required to make the connection
> once the application restarts
> 4. Active connection details of each query tool opened
> 5. Store the query that is written in the editor that may or may not
> be executed
> 6. Store the contents of the scratch pad
> 7. Store the file which is opened in the query tool with any unsaved
> changes
>
> Some questions that I have are mentioned below,
>
> 1. For desktop mode the application is opened with some query tools
> and the user closes the application and on restarts the tabs will open as
> it is and will restore the workspace and connections on query tool tabs.
> But for server mode do we need to restore the query tool tabs and
> workspace? Because we see most of the desktop applications have this
> feature.
> 2. I came across one issue reported by one user i.e
> https://github.com/pgadmin-org/pgadmin4/issues/6666, where pgAdmin
> crashed due to long SQL scripts that can be in Megabytes stored as query
> history. We fixed it by giving MAX_QUERY_LENGTH to 1000000, and
> checking if any query length is below the value then it gets stored in the
> database as query history else not. Should we go with storing the workspace
> and query tool details in SQLite DB or use a file system to store the
> details and retrieve the content accordingly?
>
>
> Please let me know your suggestions on this.
>
> Thanks
> Anil
> --
>
> <http://www.enterprisedb.com;
>
> *Anil Sahoo*
>
> Software Engineer
>
> www.enterprisedb.com
>
> Power to Postgres
>
> <https://www.linkedin.com/company/edbpostgres;
> <https://twitter.com/edbpostgres?lang=en;
> <https://www.facebook.com/EDBpostgres;
> <https://www.instagram.com/EDBpostgres/;
>
>
> On Tue, Aug 20, 2024 at 10:14 AM Aditya Toshniwal <
> [email protected]> wrote:
>
>> Hi Anil,
>>
>> There can be multiple query tools open with large files. Not entirely
>> sure if storing in SQLite DB is a good idea.
>> External databases won't come in the picture as 99.99% users will not use
>> external DB for desktop app. We're only doing this for desktop app.
>> And also consider the case where a SQL file is opened with some unsaved
>> changes.
>>
>> On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
>> wrote:
>>
>>> Hi Aditya,
>>>
>>> As we are already storing the query history in the pgAdmin 4's database
>>> file.
>>> I am planning to store the information the same way. That can be an
>>> internal database file like SQLite or external database.
>>>
>>> Let me know if you all have any suggestions on this.
>>>
>>> Thanks
>>> Anil
>>> --
>>>
>>> <http://www.enterprisedb.com;
>>>
>>> *Anil Sahoo*
>>>
>>> Software Engineer
>>>
>>> www.enterprisedb.com
>>>
>>> Power to Postgres
>>>
>>> <https://www.linkedin.com/company/edbpostgres;
>>> <https://twitter.com/edbpostgres?lang=en;
>>> <https://www.facebook.com/EDBpostgres;
>>> <https://www.instagram.com/EDBpostgres/;
>>>
>>>
>>> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
>>> [email protected]> wrote:
>>>
>>>> Hi Anil,
>>>>
>>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Yes, We will store the details that are needed to re-establish the
>>>>> connection.
>>>>>
>>>>
>>>> How/Where are you planning to store the information? Query text could
>>>> be large.
>>>>
>>>>>
>>>>> Regards
>>>>> Anil
>>>>> --
>>>>>
>>>>> <http://www.enterprisedb.com;
>>>>>
>>>>> *Anil Sahoo*
>>>>>
>>>>> Software Engineer
>>>>>
>>>>> www.enterprisedb.com
>>>>>
>>>>> Power to Postgres
>>>>>
>>>>> <https://www.linkedin.com/company/edbpostgres;
>>>>> <https://twitter.com/edbpostgres?lang=en;
>>>>> <https://www.facebook.com/EDBpostgres;
>>>>> <https://www.instagram.com/EDBpostgres/;
>>>>>
>>>>>
>>>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Hackers,
>>>>>>>
>>>>>>>
>>>>>>> This feature #3319
>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>>>>> Workspace and the Query tool panel to be saved before exiting the
>>>>>>> application and on restart it will show earlier opened panels.
>>>>>>>
>>>>>>>
>>>>>>> We are already saving the Browser layout, Query tool layout and the
>>>>>>> Object explorer tree state but to save the contents of panels we will
>>>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>>>
>>>>>>> 1. Store the query tool panels and the list of connections
>>>>>>> present in each query tool panel and the active connection
>>>>>>> 2. Store the query that is written in the editor
>>>>>>> 3. Store the contents of scratch pad
>>>>>>>
>>>>>>> The main reason that this has never been worked on is that there is
>>>>>> no way to restore the state of a connection to what it was and be sure
>>>>>> we've got it right. How do you propose to handle that? I assume in a
>>>>>> similar way to the warnings we give if a connection has to be
>>>>>> re-established?
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We will use debouncing to store the workspace data and all other
>>>>>>> data related to panels in the pgAdmin 4's configured database file. Through
>>>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>>>> interaction, and it will update the stored data related to workspace and
>>>>>>> all other panels.
>>>>>>>
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> --
>>>>>> 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/
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Aditya Toshniwal
>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>> <https://www.enterprisedb.com/;
>>>> "Don't Complain about Heat, Plant a TREE"
>>>>
>>>
>>
>> --
>> Thanks,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>> <https://www.enterprisedb.com/;
>> "Don't Complain about Heat, Plant a TREE"
>>
>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-19 11:20 Yogesh Mahajan <[email protected]>
parent: Aditya Toshniwal <[email protected]>
1 sibling, 0 replies; 24+ messages in thread
From: Yogesh Mahajan @ 2025-02-19 11:20 UTC (permalink / raw)
To: pgadmin-hackers; +Cc: Dave Page <[email protected]>; Aditya Toshniwal <[email protected]>
Hi Dave/Team,
Here are 2 storage options -
1.IndexdDB -
IndexdDB
<https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria#ot...;
is supported by all the browsers except IE.(Ref
<https://www.lambdatest.com/web-technologies/indexeddb;). Electron also
supports it.
Pros -
Low latency and less load on the pgadmin server as data will be stored at
the client side.
Cons -
In server mode, if the machine/browser is changed, pgadmin will not be able
to retrieve the data.
2.File based -
Similar to session files, we can store them in the same pgadmin data
dir.This might add a load to the pgadmin server in case of server mode.
Pros -
In any mode, data will persist.
Cons -
May introduce latency and more load on the pgadmin server as data will be
stored at the server side.
Before moving forward, can you please help to get answers for the
questions below -
1.Should the query/workspace data persist in both desktop and server mode?
Thanks,
Yogesh Mahajan
EnterpriseDB
On Thu, Jan 16, 2025 at 12:07 PM Aditya Toshniwal <
[email protected]> wrote:
> Hi Anil/Dave,
>
> Why not use browser localStorage for saving this information? It persists
> when the browser closes and is based on the URL. It is safer to store at
> the user's machine than on our server.
> For Electron also it should work.
> This will reduce load on the pgAdmin server.
>
> On Wed, Aug 28, 2024 at 12:50 PM Anil Sahoo <[email protected]>
> wrote:
>
>> Hi Hackers,
>>
>>
>> We are going to store the below details
>>
>> 1. List of Query tools opened
>> 2. List of connections present in each query tool
>> 3. Each connection’s details that are required to make the connection
>> once the application restarts
>> 4. Active connection details of each query tool opened
>> 5. Store the query that is written in the editor that may or may not
>> be executed
>> 6. Store the contents of the scratch pad
>> 7. Store the file which is opened in the query tool with any unsaved
>> changes
>>
>> Some questions that I have are mentioned below,
>>
>> 1. For desktop mode the application is opened with some query tools
>> and the user closes the application and on restarts the tabs will open as
>> it is and will restore the workspace and connections on query tool tabs.
>> But for server mode do we need to restore the query tool tabs and
>> workspace? Because we see most of the desktop applications have this
>> feature.
>> 2. I came across one issue reported by one user i.e
>> https://github.com/pgadmin-org/pgadmin4/issues/6666, where pgAdmin
>> crashed due to long SQL scripts that can be in Megabytes stored as query
>> history. We fixed it by giving MAX_QUERY_LENGTH to 1000000, and
>> checking if any query length is below the value then it gets stored in the
>> database as query history else not. Should we go with storing the workspace
>> and query tool details in SQLite DB or use a file system to store the
>> details and retrieve the content accordingly?
>>
>>
>> Please let me know your suggestions on this.
>>
>> Thanks
>> Anil
>> --
>>
>> <http://www.enterprisedb.com;
>>
>> *Anil Sahoo*
>>
>> Software Engineer
>>
>> www.enterprisedb.com
>>
>> Power to Postgres
>>
>> <https://www.linkedin.com/company/edbpostgres;
>> <https://twitter.com/edbpostgres?lang=en;
>> <https://www.facebook.com/EDBpostgres;
>> <https://www.instagram.com/EDBpostgres/;
>>
>>
>> On Tue, Aug 20, 2024 at 10:14 AM Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Anil,
>>>
>>> There can be multiple query tools open with large files. Not entirely
>>> sure if storing in SQLite DB is a good idea.
>>> External databases won't come in the picture as 99.99% users will not
>>> use external DB for desktop app. We're only doing this for desktop app.
>>> And also consider the case where a SQL file is opened with some unsaved
>>> changes.
>>>
>>> On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
>>> wrote:
>>>
>>>> Hi Aditya,
>>>>
>>>> As we are already storing the query history in the pgAdmin 4's database
>>>> file.
>>>> I am planning to store the information the same way. That can be an
>>>> internal database file like SQLite or external database.
>>>>
>>>> Let me know if you all have any suggestions on this.
>>>>
>>>> Thanks
>>>> Anil
>>>> --
>>>>
>>>> <http://www.enterprisedb.com;
>>>>
>>>> *Anil Sahoo*
>>>>
>>>> Software Engineer
>>>>
>>>> www.enterprisedb.com
>>>>
>>>> Power to Postgres
>>>>
>>>> <https://www.linkedin.com/company/edbpostgres;
>>>> <https://twitter.com/edbpostgres?lang=en;
>>>> <https://www.facebook.com/EDBpostgres;
>>>> <https://www.instagram.com/EDBpostgres/;
>>>>
>>>>
>>>> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Anil,
>>>>>
>>>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Yes, We will store the details that are needed to re-establish the
>>>>>> connection.
>>>>>>
>>>>>
>>>>> How/Where are you planning to store the information? Query text could
>>>>> be large.
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Anil
>>>>>> --
>>>>>>
>>>>>> <http://www.enterprisedb.com;
>>>>>>
>>>>>> *Anil Sahoo*
>>>>>>
>>>>>> Software Engineer
>>>>>>
>>>>>> www.enterprisedb.com
>>>>>>
>>>>>> Power to Postgres
>>>>>>
>>>>>> <https://www.linkedin.com/company/edbpostgres;
>>>>>> <https://twitter.com/edbpostgres?lang=en;
>>>>>> <https://www.facebook.com/EDBpostgres;
>>>>>> <https://www.instagram.com/EDBpostgres/;
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Hackers,
>>>>>>>>
>>>>>>>>
>>>>>>>> This feature #3319
>>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>>>>>> Workspace and the Query tool panel to be saved before exiting the
>>>>>>>> application and on restart it will show earlier opened panels.
>>>>>>>>
>>>>>>>>
>>>>>>>> We are already saving the Browser layout, Query tool layout and the
>>>>>>>> Object explorer tree state but to save the contents of panels we will
>>>>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>>>>
>>>>>>>> 1. Store the query tool panels and the list of connections
>>>>>>>> present in each query tool panel and the active connection
>>>>>>>> 2. Store the query that is written in the editor
>>>>>>>> 3. Store the contents of scratch pad
>>>>>>>>
>>>>>>>> The main reason that this has never been worked on is that there is
>>>>>>> no way to restore the state of a connection to what it was and be sure
>>>>>>> we've got it right. How do you propose to handle that? I assume in a
>>>>>>> similar way to the warnings we give if a connection has to be
>>>>>>> re-established?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We will use debouncing to store the workspace data and all other
>>>>>>>> data related to panels in the pgAdmin 4's configured database file. Through
>>>>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>>>>> interaction, and it will update the stored data related to workspace and
>>>>>>>> all other panels.
>>>>>>>>
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>> --
>>>>>>> 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/
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>> <https://www.enterprisedb.com/;
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
> <https://www.enterprisedb.com/;
> "Don't Complain about Heat, Plant a TREE"
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-19 11:41 Dave Page <[email protected]>
parent: Aditya Toshniwal <[email protected]>
1 sibling, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-02-19 11:41 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Anil Sahoo <[email protected]>; pgadmin-hackers
Hi
On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
[email protected]> wrote:
> Hi Anil/Dave,
>
> Why not use browser localStorage for saving this information? It persists
> when the browser closes and is based on the URL. It is safer to store at
> the user's machine than on our server.
> For Electron also it should work.
> This will reduce load on the pgAdmin server.
>
Because it stores it at the users machine and not on the pgAdmin server,
and thus state cannot be restored if the user is on a different machine. I
think that's a compelling feature.
That said, I think this is largely irrelevant until the fundamental problem
is solved. e.g. how do we restore the state of the session (spoiler: it's
almost certainly not possible, unless we can figure out all the
session-changing side effects of every query, stored procedure/function
etc. that may have been directly or indirectly called).
Or, we make a decision not to bother with that, and to give the user
suitable warnings such as we do when we perform a reconnect.
>
> On Wed, Aug 28, 2024 at 12:50 PM Anil Sahoo <[email protected]>
> wrote:
>
>> Hi Hackers,
>>
>>
>> We are going to store the below details
>>
>> 1. List of Query tools opened
>> 2. List of connections present in each query tool
>> 3. Each connection’s details that are required to make the connection
>> once the application restarts
>> 4. Active connection details of each query tool opened
>> 5. Store the query that is written in the editor that may or may not
>> be executed
>> 6. Store the contents of the scratch pad
>> 7. Store the file which is opened in the query tool with any unsaved
>> changes
>>
>> Some questions that I have are mentioned below,
>>
>> 1. For desktop mode the application is opened with some query tools
>> and the user closes the application and on restarts the tabs will open as
>> it is and will restore the workspace and connections on query tool tabs.
>> But for server mode do we need to restore the query tool tabs and
>> workspace? Because we see most of the desktop applications have this
>> feature.
>> 2. I came across one issue reported by one user i.e
>> https://github.com/pgadmin-org/pgadmin4/issues/6666, where pgAdmin
>> crashed due to long SQL scripts that can be in Megabytes stored as query
>> history. We fixed it by giving MAX_QUERY_LENGTH to 1000000, and
>> checking if any query length is below the value then it gets stored in the
>> database as query history else not. Should we go with storing the workspace
>> and query tool details in SQLite DB or use a file system to store the
>> details and retrieve the content accordingly?
>>
>>
>> Please let me know your suggestions on this.
>>
>> Thanks
>> Anil
>> --
>>
>> <http://www.enterprisedb.com;
>>
>> *Anil Sahoo*
>>
>> Software Engineer
>>
>> www.enterprisedb.com
>>
>> Power to Postgres
>>
>> <https://www.linkedin.com/company/edbpostgres;
>> <https://twitter.com/edbpostgres?lang=en;
>> <https://www.facebook.com/EDBpostgres;
>> <https://www.instagram.com/EDBpostgres/;
>>
>>
>> On Tue, Aug 20, 2024 at 10:14 AM Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Anil,
>>>
>>> There can be multiple query tools open with large files. Not entirely
>>> sure if storing in SQLite DB is a good idea.
>>> External databases won't come in the picture as 99.99% users will not
>>> use external DB for desktop app. We're only doing this for desktop app.
>>> And also consider the case where a SQL file is opened with some unsaved
>>> changes.
>>>
>>> On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
>>> wrote:
>>>
>>>> Hi Aditya,
>>>>
>>>> As we are already storing the query history in the pgAdmin 4's database
>>>> file.
>>>> I am planning to store the information the same way. That can be an
>>>> internal database file like SQLite or external database.
>>>>
>>>> Let me know if you all have any suggestions on this.
>>>>
>>>> Thanks
>>>> Anil
>>>> --
>>>>
>>>> <http://www.enterprisedb.com;
>>>>
>>>> *Anil Sahoo*
>>>>
>>>> Software Engineer
>>>>
>>>> www.enterprisedb.com
>>>>
>>>> Power to Postgres
>>>>
>>>> <https://www.linkedin.com/company/edbpostgres;
>>>> <https://twitter.com/edbpostgres?lang=en;
>>>> <https://www.facebook.com/EDBpostgres;
>>>> <https://www.instagram.com/EDBpostgres/;
>>>>
>>>>
>>>> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Anil,
>>>>>
>>>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Yes, We will store the details that are needed to re-establish the
>>>>>> connection.
>>>>>>
>>>>>
>>>>> How/Where are you planning to store the information? Query text could
>>>>> be large.
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Anil
>>>>>> --
>>>>>>
>>>>>> <http://www.enterprisedb.com;
>>>>>>
>>>>>> *Anil Sahoo*
>>>>>>
>>>>>> Software Engineer
>>>>>>
>>>>>> www.enterprisedb.com
>>>>>>
>>>>>> Power to Postgres
>>>>>>
>>>>>> <https://www.linkedin.com/company/edbpostgres;
>>>>>> <https://twitter.com/edbpostgres?lang=en;
>>>>>> <https://www.facebook.com/EDBpostgres;
>>>>>> <https://www.instagram.com/EDBpostgres/;
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Hackers,
>>>>>>>>
>>>>>>>>
>>>>>>>> This feature #3319
>>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands the
>>>>>>>> Workspace and the Query tool panel to be saved before exiting the
>>>>>>>> application and on restart it will show earlier opened panels.
>>>>>>>>
>>>>>>>>
>>>>>>>> We are already saving the Browser layout, Query tool layout and the
>>>>>>>> Object explorer tree state but to save the contents of panels we will
>>>>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>>>>
>>>>>>>> 1. Store the query tool panels and the list of connections
>>>>>>>> present in each query tool panel and the active connection
>>>>>>>> 2. Store the query that is written in the editor
>>>>>>>> 3. Store the contents of scratch pad
>>>>>>>>
>>>>>>>> The main reason that this has never been worked on is that there is
>>>>>>> no way to restore the state of a connection to what it was and be sure
>>>>>>> we've got it right. How do you propose to handle that? I assume in a
>>>>>>> similar way to the warnings we give if a connection has to be
>>>>>>> re-established?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We will use debouncing to store the workspace data and all other
>>>>>>>> data related to panels in the pgAdmin 4's configured database file. Through
>>>>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>>>>> interaction, and it will update the stored data related to workspace and
>>>>>>>> all other panels.
>>>>>>>>
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>> --
>>>>>>> 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/
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Aditya Toshniwal
>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>> <https://www.enterprisedb.com/;
>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>
>>>>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>> <https://www.enterprisedb.com/;
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
> <https://www.enterprisedb.com/;
> "Don't Complain about Heat, Plant a TREE"
>
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-19 12:24 Yogesh Mahajan <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Yogesh Mahajan @ 2025-02-19 12:24 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Aditya Toshniwal <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
Hi,
On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
> Hi
>
> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
> [email protected]> wrote:
>
>> Hi Anil/Dave,
>>
>> Why not use browser localStorage for saving this information? It persists
>> when the browser closes and is based on the URL. It is safer to store at
>> the user's machine than on our server.
>> For Electron also it should work.
>> This will reduce load on the pgAdmin server.
>>
>
> Because it stores it at the users machine and not on the pgAdmin server,
> and thus state cannot be restored if the user is on a different machine. I
> think that's a compelling feature.
>
> That said, I think this is largely irrelevant until the fundamental
> problem is solved. e.g. how do we restore the state of the session
> (spoiler: it's almost certainly not possible, unless we can figure out all
> the session-changing side effects of every query, stored procedure/function
> etc. that may have been directly or indirectly called).
>
> Or, we make a decision not to bother with that, and to give the user
> suitable warnings such as we do when we perform a reconnect.
>
If I understand correctly, Users are complaining about losing unsaved data
in the query tool and not about data output or session state. Hence just
reopening the query tool with only data should be suffice.
Thanks,
Yogesh Mahajan
EnterpriseDB
>
>
>>
>> On Wed, Aug 28, 2024 at 12:50 PM Anil Sahoo <[email protected]>
>> wrote:
>>
>>> Hi Hackers,
>>>
>>>
>>> We are going to store the below details
>>>
>>> 1. List of Query tools opened
>>> 2. List of connections present in each query tool
>>> 3. Each connection’s details that are required to make the
>>> connection once the application restarts
>>> 4. Active connection details of each query tool opened
>>> 5. Store the query that is written in the editor that may or may not
>>> be executed
>>> 6. Store the contents of the scratch pad
>>> 7. Store the file which is opened in the query tool with any unsaved
>>> changes
>>>
>>> Some questions that I have are mentioned below,
>>>
>>> 1. For desktop mode the application is opened with some query tools
>>> and the user closes the application and on restarts the tabs will open as
>>> it is and will restore the workspace and connections on query tool tabs.
>>> But for server mode do we need to restore the query tool tabs and
>>> workspace? Because we see most of the desktop applications have this
>>> feature.
>>> 2. I came across one issue reported by one user i.e
>>> https://github.com/pgadmin-org/pgadmin4/issues/6666, where pgAdmin
>>> crashed due to long SQL scripts that can be in Megabytes stored as query
>>> history. We fixed it by giving MAX_QUERY_LENGTH to 1000000, and
>>> checking if any query length is below the value then it gets stored in the
>>> database as query history else not. Should we go with storing the workspace
>>> and query tool details in SQLite DB or use a file system to store the
>>> details and retrieve the content accordingly?
>>>
>>>
>>> Please let me know your suggestions on this.
>>>
>>> Thanks
>>> Anil
>>> --
>>>
>>> <http://www.enterprisedb.com;
>>>
>>> *Anil Sahoo*
>>>
>>> Software Engineer
>>>
>>> www.enterprisedb.com
>>>
>>> Power to Postgres
>>>
>>> <https://www.linkedin.com/company/edbpostgres;
>>> <https://twitter.com/edbpostgres?lang=en;
>>> <https://www.facebook.com/EDBpostgres;
>>> <https://www.instagram.com/EDBpostgres/;
>>>
>>>
>>> On Tue, Aug 20, 2024 at 10:14 AM Aditya Toshniwal <
>>> [email protected]> wrote:
>>>
>>>> Hi Anil,
>>>>
>>>> There can be multiple query tools open with large files. Not entirely
>>>> sure if storing in SQLite DB is a good idea.
>>>> External databases won't come in the picture as 99.99% users will not
>>>> use external DB for desktop app. We're only doing this for desktop app.
>>>> And also consider the case where a SQL file is opened with some unsaved
>>>> changes.
>>>>
>>>> On Tue, Aug 20, 2024 at 9:11 AM Anil Sahoo <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Aditya,
>>>>>
>>>>> As we are already storing the query history in the pgAdmin 4's
>>>>> database file.
>>>>> I am planning to store the information the same way. That can be an
>>>>> internal database file like SQLite or external database.
>>>>>
>>>>> Let me know if you all have any suggestions on this.
>>>>>
>>>>> Thanks
>>>>> Anil
>>>>> --
>>>>>
>>>>> <http://www.enterprisedb.com;
>>>>>
>>>>> *Anil Sahoo*
>>>>>
>>>>> Software Engineer
>>>>>
>>>>> www.enterprisedb.com
>>>>>
>>>>> Power to Postgres
>>>>>
>>>>> <https://www.linkedin.com/company/edbpostgres;
>>>>> <https://twitter.com/edbpostgres?lang=en;
>>>>> <https://www.facebook.com/EDBpostgres;
>>>>> <https://www.instagram.com/EDBpostgres/;
>>>>>
>>>>>
>>>>> On Mon, Aug 19, 2024 at 11:40 AM Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Anil,
>>>>>>
>>>>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Yes, We will store the details that are needed to re-establish the
>>>>>>> connection.
>>>>>>>
>>>>>>
>>>>>> How/Where are you planning to store the information? Query text could
>>>>>> be large.
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Anil
>>>>>>> --
>>>>>>>
>>>>>>> <http://www.enterprisedb.com;
>>>>>>>
>>>>>>> *Anil Sahoo*
>>>>>>>
>>>>>>> Software Engineer
>>>>>>>
>>>>>>> www.enterprisedb.com
>>>>>>>
>>>>>>> Power to Postgres
>>>>>>>
>>>>>>> <https://www.linkedin.com/company/edbpostgres;
>>>>>>> <https://twitter.com/edbpostgres?lang=en;
>>>>>>> <https://www.facebook.com/EDBpostgres;
>>>>>>> <https://www.instagram.com/EDBpostgres/;
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 12, 2024 at 2:08 PM Dave Page <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Hackers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This feature #3319
>>>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/3319;, demands
>>>>>>>>> the Workspace and the Query tool panel to be saved before exiting the
>>>>>>>>> application and on restart it will show earlier opened panels.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are already saving the Browser layout, Query tool layout and
>>>>>>>>> the Object explorer tree state but to save the contents of panels we will
>>>>>>>>> initially start with the Query tool. The below implementation will be done,
>>>>>>>>>
>>>>>>>>> 1. Store the query tool panels and the list of connections
>>>>>>>>> present in each query tool panel and the active connection
>>>>>>>>> 2. Store the query that is written in the editor
>>>>>>>>> 3. Store the contents of scratch pad
>>>>>>>>>
>>>>>>>>> The main reason that this has never been worked on is that there
>>>>>>>> is no way to restore the state of a connection to what it was and be sure
>>>>>>>> we've got it right. How do you propose to handle that? I assume in a
>>>>>>>> similar way to the warnings we give if a connection has to be
>>>>>>>> re-established?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We will use debouncing to store the workspace data and all other
>>>>>>>>> data related to panels in the pgAdmin 4's configured database file. Through
>>>>>>>>> debouncing we will be able to call the API at certain intervals of user
>>>>>>>>> interaction, and it will update the stored data related to workspace and
>>>>>>>>> all other panels.
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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/
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Aditya Toshniwal
>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>> <https://www.enterprisedb.com/;
>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Aditya Toshniwal
>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>> <https://www.enterprisedb.com/;
>>>> "Don't Complain about Heat, Plant a TREE"
>>>>
>>>
>>
>> --
>> Thanks,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
>> <https://www.enterprisedb.com/;
>> "Don't Complain about Heat, Plant a TREE"
>>
>
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-19 13:25 Dave Page <[email protected]>
parent: Yogesh Mahajan <[email protected]>
0 siblings, 2 replies; 24+ messages in thread
From: Dave Page @ 2025-02-19 13:25 UTC (permalink / raw)
To: Yogesh Mahajan <[email protected]>; +Cc: Aditya Toshniwal <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
[email protected]> wrote:
>
> Hi,
>
> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>
>> Hi
>>
>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Anil/Dave,
>>>
>>> Why not use browser localStorage for saving this information? It
>>> persists when the browser closes and is based on the URL. It is safer to
>>> store at the user's machine than on our server.
>>> For Electron also it should work.
>>> This will reduce load on the pgAdmin server.
>>>
>>
>> Because it stores it at the users machine and not on the pgAdmin server,
>> and thus state cannot be restored if the user is on a different machine. I
>> think that's a compelling feature.
>>
>> That said, I think this is largely irrelevant until the fundamental
>> problem is solved. e.g. how do we restore the state of the session
>> (spoiler: it's almost certainly not possible, unless we can figure out all
>> the session-changing side effects of every query, stored procedure/function
>> etc. that may have been directly or indirectly called).
>>
>> Or, we make a decision not to bother with that, and to give the user
>> suitable warnings such as we do when we perform a reconnect.
>>
>
> If I understand correctly, Users are complaining about losing unsaved data
> in the query tool and not about data output or session state. Hence just
> reopening the query tool with only data should be suffice.
>
I'm sure that will suffice for 95%+ of users. The ones I'm concerned about
are those who (for example) have done SET search_path = ... and then
performed some destructive operation that worked as expected because of the
earlier SET, but might cause data loss or unexpected consequences if run
without the SET.
Granted, that class of issues is likely to affect only a small number of
users in reality, but the consequences could easily be data loss.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-19 13:41 Anthony DeBarros <[email protected]>
parent: Dave Page <[email protected]>
1 sibling, 0 replies; 24+ messages in thread
From: Anthony DeBarros @ 2025-02-19 13:41 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Yogesh Mahajan <[email protected]>; Aditya Toshniwal <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
> If I understand correctly, Users are complaining about losing unsaved data
>> in the query tool and not about data output or session state. Hence just
>> reopening the query tool with only data should be suffice.
>>
>
> I'm sure that will suffice for 95%+ of users. The ones I'm concerned about
> are those who (for example) have done SET search_path = ... and then
> performed some destructive operation that worked as expected because of the
> earlier SET, but might cause data loss or unexpected consequences if run
> without the SET.
>
> Granted, that class of issues is likely to affect only a small number of
> users in reality, but the consequences could easily be data loss.
>
>
Just a thought from an onlooker. My main request for this feature would be
to re-open query tool tabs with the contents restored, whether I had saved
the files or not. I don't think I would expect to see any results populated
in the results grid, nor would I expect temporary SET operations to also be
restored.
I am curious about a comment about saving data on the pgAdmin server. Would
that mean sending the contents of my files to a server outside my org?
Forgive me if I am misunderstanding.
Thanks,
Anthony
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-20 03:52 Aditya Toshniwal <[email protected]>
parent: Dave Page <[email protected]>
1 sibling, 1 reply; 24+ messages in thread
From: Aditya Toshniwal @ 2025-02-20 03:52 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Yogesh Mahajan <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
Hi Dave,
On Wed, Feb 19, 2025 at 6:55 PM Dave Page <[email protected]> wrote:
>
>
> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
> [email protected]> wrote:
>
>>
>> Hi,
>>
>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>>
>>> Hi
>>>
>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>>> [email protected]> wrote:
>>>
>>>> Hi Anil/Dave,
>>>>
>>>> Why not use browser localStorage for saving this information? It
>>>> persists when the browser closes and is based on the URL. It is safer to
>>>> store at the user's machine than on our server.
>>>> For Electron also it should work.
>>>> This will reduce load on the pgAdmin server.
>>>>
>>>
>>> Because it stores it at the users machine and not on the pgAdmin server,
>>> and thus state cannot be restored if the user is on a different machine. I
>>> think that's a compelling feature.
>>>
>>> That said, I think this is largely irrelevant until the fundamental
>>> problem is solved. e.g. how do we restore the state of the session
>>> (spoiler: it's almost certainly not possible, unless we can figure out all
>>> the session-changing side effects of every query, stored procedure/function
>>> etc. that may have been directly or indirectly called).
>>>
>>> Or, we make a decision not to bother with that, and to give the user
>>> suitable warnings such as we do when we perform a reconnect.
>>>
>>
>> If I understand correctly, Users are complaining about losing unsaved
>> data in the query tool and not about data output or session state. Hence
>> just reopening the query tool with only data should be suffice.
>>
>
> I'm sure that will suffice for 95%+ of users. The ones I'm concerned about
> are those who (for example) have done SET search_path = ... and then
> performed some destructive operation that worked as expected because of the
> earlier SET, but might cause data loss or unexpected consequences if run
> without the SET.
>
> Granted, that class of issues is likely to affect only a small number of
> users in reality, but the consequences could easily be data loss.
>
It may be compelling to restore your workspace on any browser in the world
but is it worth it? I mean think about the overhead it will put on the
pgAdmin server. Plus the storage it will require on the server side.
Already people are asking to make pgAdmin storage free by putting sessions
in db instead of file based and so on. Also, the information cannot be
saved as is, it needs to be encrypted (more overhead).
On a slower internet, restoring might take a long time. We'll have an
advantage of storing on the client side and it will cover most of the users
with good performance.
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-20 09:51 Dave Page <[email protected]>
parent: Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-02-20 09:51 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Yogesh Mahajan <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal <
[email protected]> wrote:
> Hi Dave,
>
> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
>> [email protected]> wrote:
>>
>>>
>>> Hi,
>>>
>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>>>
>>>> Hi
>>>>
>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Anil/Dave,
>>>>>
>>>>> Why not use browser localStorage for saving this information? It
>>>>> persists when the browser closes and is based on the URL. It is safer to
>>>>> store at the user's machine than on our server.
>>>>> For Electron also it should work.
>>>>> This will reduce load on the pgAdmin server.
>>>>>
>>>>
>>>> Because it stores it at the users machine and not on the pgAdmin
>>>> server, and thus state cannot be restored if the user is on a different
>>>> machine. I think that's a compelling feature.
>>>>
>>>> That said, I think this is largely irrelevant until the fundamental
>>>> problem is solved. e.g. how do we restore the state of the session
>>>> (spoiler: it's almost certainly not possible, unless we can figure out all
>>>> the session-changing side effects of every query, stored procedure/function
>>>> etc. that may have been directly or indirectly called).
>>>>
>>>> Or, we make a decision not to bother with that, and to give the user
>>>> suitable warnings such as we do when we perform a reconnect.
>>>>
>>>
>>> If I understand correctly, Users are complaining about losing unsaved
>>> data in the query tool and not about data output or session state. Hence
>>> just reopening the query tool with only data should be suffice.
>>>
>>
>> I'm sure that will suffice for 95%+ of users. The ones I'm concerned
>> about are those who (for example) have done SET search_path = ... and then
>> performed some destructive operation that worked as expected because of the
>> earlier SET, but might cause data loss or unexpected consequences if run
>> without the SET.
>>
>> Granted, that class of issues is likely to affect only a small number of
>> users in reality, but the consequences could easily be data loss.
>>
>
> It may be compelling to restore your workspace on any browser in the world
> but is it worth it? I mean think about the overhead it will put on the
> pgAdmin server. Plus the storage it will require on the server side.
> Already people are asking to make pgAdmin storage free by putting sessions
> in db instead of file based and so on. Also, the information cannot be
> saved as is, it needs to be encrypted (more overhead).
> On a slower internet, restoring might take a long time. We'll have an
> advantage of storing on the client side and it will cover most of the users
> with good performance.
>
How big do you think the average SQL query/script is? Even in outlier cases
where they might run into a megabyte or two, that's still trivial compared
to what people download browsing Facebook on their phone for example.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-20 10:55 Aditya Toshniwal <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Aditya Toshniwal @ 2025-02-20 10:55 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Yogesh Mahajan <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
Hi Dave,
On Thu, Feb 20, 2025 at 3:22 PM Dave Page <[email protected]> wrote:
>
>
> On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal <
> [email protected]> wrote:
>
>> Hi Dave,
>>
>> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <[email protected]> wrote:
>>
>>>
>>>
>>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
>>> [email protected]> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Anil/Dave,
>>>>>>
>>>>>> Why not use browser localStorage for saving this information? It
>>>>>> persists when the browser closes and is based on the URL. It is safer to
>>>>>> store at the user's machine than on our server.
>>>>>> For Electron also it should work.
>>>>>> This will reduce load on the pgAdmin server.
>>>>>>
>>>>>
>>>>> Because it stores it at the users machine and not on the pgAdmin
>>>>> server, and thus state cannot be restored if the user is on a different
>>>>> machine. I think that's a compelling feature.
>>>>>
>>>>> That said, I think this is largely irrelevant until the fundamental
>>>>> problem is solved. e.g. how do we restore the state of the session
>>>>> (spoiler: it's almost certainly not possible, unless we can figure out all
>>>>> the session-changing side effects of every query, stored procedure/function
>>>>> etc. that may have been directly or indirectly called).
>>>>>
>>>>> Or, we make a decision not to bother with that, and to give the user
>>>>> suitable warnings such as we do when we perform a reconnect.
>>>>>
>>>>
>>>> If I understand correctly, Users are complaining about losing unsaved
>>>> data in the query tool and not about data output or session state. Hence
>>>> just reopening the query tool with only data should be suffice.
>>>>
>>>
>>> I'm sure that will suffice for 95%+ of users. The ones I'm concerned
>>> about are those who (for example) have done SET search_path = ... and then
>>> performed some destructive operation that worked as expected because of the
>>> earlier SET, but might cause data loss or unexpected consequences if run
>>> without the SET.
>>>
>>> Granted, that class of issues is likely to affect only a small number of
>>> users in reality, but the consequences could easily be data loss.
>>>
>>
>> It may be compelling to restore your workspace on any browser in the
>> world but is it worth it? I mean think about the overhead it will put on
>> the pgAdmin server. Plus the storage it will require on the server side.
>> Already people are asking to make pgAdmin storage free by putting sessions
>> in db instead of file based and so on. Also, the information cannot be
>> saved as is, it needs to be encrypted (more overhead).
>> On a slower internet, restoring might take a long time. We'll have an
>> advantage of storing on the client side and it will cover most of the users
>> with good performance.
>>
>
> How big do you think the average SQL query/script is? Even in outlier
> cases where they might run into a megabyte or two, that's still trivial
> compared to what people download browsing Facebook on their phone for
> example.
>
In server mode, the user count may go up. The number of open SQL editor
tabs may go up. And there is encryption/decryption that is needed as well.
Users changing a browser is also less likely. The feature is most useful
for desktop users.
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-02-20 11:02 Dave Page <[email protected]>
parent: Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-02-20 11:02 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Yogesh Mahajan <[email protected]>; Anil Sahoo <[email protected]>; pgadmin-hackers
On Thu, 20 Feb 2025 at 10:56, Aditya Toshniwal <
[email protected]> wrote:
> Hi Dave,
>
> On Thu, Feb 20, 2025 at 3:22 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Dave,
>>>
>>> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Anil/Dave,
>>>>>>>
>>>>>>> Why not use browser localStorage for saving this information? It
>>>>>>> persists when the browser closes and is based on the URL. It is safer to
>>>>>>> store at the user's machine than on our server.
>>>>>>> For Electron also it should work.
>>>>>>> This will reduce load on the pgAdmin server.
>>>>>>>
>>>>>>
>>>>>> Because it stores it at the users machine and not on the pgAdmin
>>>>>> server, and thus state cannot be restored if the user is on a different
>>>>>> machine. I think that's a compelling feature.
>>>>>>
>>>>>> That said, I think this is largely irrelevant until the fundamental
>>>>>> problem is solved. e.g. how do we restore the state of the session
>>>>>> (spoiler: it's almost certainly not possible, unless we can figure out all
>>>>>> the session-changing side effects of every query, stored procedure/function
>>>>>> etc. that may have been directly or indirectly called).
>>>>>>
>>>>>> Or, we make a decision not to bother with that, and to give the user
>>>>>> suitable warnings such as we do when we perform a reconnect.
>>>>>>
>>>>>
>>>>> If I understand correctly, Users are complaining about losing unsaved
>>>>> data in the query tool and not about data output or session state. Hence
>>>>> just reopening the query tool with only data should be suffice.
>>>>>
>>>>
>>>> I'm sure that will suffice for 95%+ of users. The ones I'm concerned
>>>> about are those who (for example) have done SET search_path = ... and then
>>>> performed some destructive operation that worked as expected because of the
>>>> earlier SET, but might cause data loss or unexpected consequences if run
>>>> without the SET.
>>>>
>>>> Granted, that class of issues is likely to affect only a small number
>>>> of users in reality, but the consequences could easily be data loss.
>>>>
>>>
>>> It may be compelling to restore your workspace on any browser in the
>>> world but is it worth it? I mean think about the overhead it will put on
>>> the pgAdmin server. Plus the storage it will require on the server side.
>>> Already people are asking to make pgAdmin storage free by putting sessions
>>> in db instead of file based and so on. Also, the information cannot be
>>> saved as is, it needs to be encrypted (more overhead).
>>> On a slower internet, restoring might take a long time. We'll have an
>>> advantage of storing on the client side and it will cover most of the users
>>> with good performance.
>>>
>>
>> How big do you think the average SQL query/script is? Even in outlier
>> cases where they might run into a megabyte or two, that's still trivial
>> compared to what people download browsing Facebook on their phone for
>> example.
>>
> In server mode, the user count may go up. The number of open SQL editor
> tabs may go up. And there is encryption/decryption that is needed as well.
> Users changing a browser is also less likely. The feature is most useful
> for desktop users.
>
Sure. Until you get to 100's or 1000's of users, it's still almost
certainly a trivial amount of storage/traffic.
Keep in mind as well that we're already storing the contents of the query
tool every time the execute button is pressed, which might be dozens of
times in a session. We're talking here about adding 1 row that we just
update every 30 seconds or so.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-11 08:31 Yogesh Mahajan <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Yogesh Mahajan @ 2025-03-11 08:31 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
Hello Team,
Couple of more questions arose during discussion -
1.What all tools should we reopen while restoration? It could be Query
tool, ERD, Psql, Schema diff as of now may get additional in future.
2.Can we use an existing crypt key to encrypt the query data or simply json
encoding should be enough?
Thanks,
Yogesh Mahajan
EnterpriseDB
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:07 Dave Page <[email protected]>
parent: Yogesh Mahajan <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-03-13 11:07 UTC (permalink / raw)
To: Yogesh Mahajan <[email protected]>; +Cc: pgadmin-hackers
On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
[email protected]> wrote:
> Hello Team,
>
> Couple of more questions arose during discussion -
>
> 1.What all tools should we reopen while restoration? It could be Query
> tool, ERD, Psql, Schema diff as of now may get additional in future.
>
Yes :-). Ideally, as much of the original state as possible should be
restored.
> 2.Can we use an existing crypt key to encrypt the query data or simply
> json encoding should be enough?
>
We're already storing the query history, so we should follow the precedent
there.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:20 Yogesh Mahajan <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Yogesh Mahajan @ 2025-03-13 11:20 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
Hi Dave,
Couple of follow up questions -
Thanks,
Yogesh Mahajan
EnterpriseDB
On Thu, Mar 13, 2025 at 4:37 PM Dave Page <[email protected]> wrote:
>
>
> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
> [email protected]> wrote:
>
>> Hello Team,
>>
>> Couple of more questions arose during discussion -
>>
>> 1.What all tools should we reopen while restoration? It could be Query
>> tool, ERD, Psql, Schema diff as of now may get additional in future.
>>
>
> Yes :-). Ideally, as much of the original state as possible should be
> restored.
>
So, should we open the psql without data and schema diff without comparison
results?
Also for the query tools open with an ad-hoc server, should we just open a
query tool with data without connections?
>
>> 2.Can we use an existing crypt key to encrypt the query data or simply
>> json encoding should be enough?
>>
>
> We're already storing the query history, so we should follow the precedent
> there.
>
Currently we are storing this data with json encoding done by the
request module.
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:28 Dave Page <[email protected]>
parent: Yogesh Mahajan <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-03-13 11:28 UTC (permalink / raw)
To: Yogesh Mahajan <[email protected]>; +Cc: pgadmin-hackers
Hi
On Thu, 13 Mar 2025 at 11:20, Yogesh Mahajan <
[email protected]> wrote:
> Hi Dave,
>
> Couple of follow up questions -
>
> Thanks,
> Yogesh Mahajan
> EnterpriseDB
>
>
> On Thu, Mar 13, 2025 at 4:37 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
>> [email protected]> wrote:
>>
>>> Hello Team,
>>>
>>> Couple of more questions arose during discussion -
>>>
>>> 1.What all tools should we reopen while restoration? It could be Query
>>> tool, ERD, Psql, Schema diff as of now may get additional in future.
>>>
>>
>> Yes :-). Ideally, as much of the original state as possible should be
>> restored.
>>
>
> So, should we open the psql without data and schema diff without
> comparison results?
>
I don't see that we have any choice for psql. We absolutely should *not*
attempt to automatically re-run user queries.
For the schema diff, yes, that could be very expensive. The user can press
the button if they want to incur that cost.
> Also for the query tools open with an ad-hoc server, should we just open a
> query tool with data without connections?
>
>
>>
>>> 2.Can we use an existing crypt key to encrypt the query data or simply
>>> json encoding should be enough?
>>>
>>
>> We're already storing the query history, so we should follow the
>> precedent there.
>>
> Currently we are storing this data with json encoding done by the
> request module.
>
>
>> --
>> Dave Page
>> pgAdmin: https://www.pgadmin.org
>> PostgreSQL: https://www.postgresql.org
>> pgEdge: https://www.pgedge.com
>>
>>
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:35 Yogesh Mahajan <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Yogesh Mahajan @ 2025-03-13 11:35 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
Hi Dave,
What about the query tools opened with an ad-hoc server, should we just
open a query tool with data without connections?
Thanks,
Yogesh Mahajan
EnterpriseDB
On Thu, Mar 13, 2025 at 4:59 PM Dave Page <[email protected]> wrote:
> Hi
>
> On Thu, 13 Mar 2025 at 11:20, Yogesh Mahajan <
> [email protected]> wrote:
>
>> Hi Dave,
>>
>> Couple of follow up questions -
>>
>> Thanks,
>> Yogesh Mahajan
>> EnterpriseDB
>>
>>
>> On Thu, Mar 13, 2025 at 4:37 PM Dave Page <[email protected]> wrote:
>>
>>>
>>>
>>> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
>>> [email protected]> wrote:
>>>
>>>> Hello Team,
>>>>
>>>> Couple of more questions arose during discussion -
>>>>
>>>> 1.What all tools should we reopen while restoration? It could be Query
>>>> tool, ERD, Psql, Schema diff as of now may get additional in future.
>>>>
>>>
>>> Yes :-). Ideally, as much of the original state as possible should be
>>> restored.
>>>
>>
>> So, should we open the psql without data and schema diff without
>> comparison results?
>>
>
> I don't see that we have any choice for psql. We absolutely should *not*
> attempt to automatically re-run user queries.
>
> For the schema diff, yes, that could be very expensive. The user can press
> the button if they want to incur that cost.
>
>
>> Also for the query tools open with an ad-hoc server, should we just open
>> a query tool with data without connections?
>>
>>
>>>
>>>> 2.Can we use an existing crypt key to encrypt the query data or simply
>>>> json encoding should be enough?
>>>>
>>>
>>> We're already storing the query history, so we should follow the
>>> precedent there.
>>>
>> Currently we are storing this data with json encoding done by the
>> request module.
>>
>>
>>> --
>>> Dave Page
>>> pgAdmin: https://www.pgadmin.org
>>> PostgreSQL: https://www.postgresql.org
>>> pgEdge: https://www.pgedge.com
>>>
>>>
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:36 Dave Page <[email protected]>
parent: Yogesh Mahajan <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Dave Page @ 2025-03-13 11:36 UTC (permalink / raw)
To: Yogesh Mahajan <[email protected]>; +Cc: pgadmin-hackers
Hi
On Thu, 13 Mar 2025 at 11:35, Yogesh Mahajan <
[email protected]> wrote:
> Hi Dave,
>
> What about the query tools opened with an ad-hoc server, should we just
> open a query tool with data without connections?
>
Can we not save the connection parameters used in the JSON (excluding the
password that we can prompt for of course)?
>
> Thanks,
> Yogesh Mahajan
> EnterpriseDB
>
>
> On Thu, Mar 13, 2025 at 4:59 PM Dave Page <[email protected]> wrote:
>
>> Hi
>>
>> On Thu, 13 Mar 2025 at 11:20, Yogesh Mahajan <
>> [email protected]> wrote:
>>
>>> Hi Dave,
>>>
>>> Couple of follow up questions -
>>>
>>> Thanks,
>>> Yogesh Mahajan
>>> EnterpriseDB
>>>
>>>
>>> On Thu, Mar 13, 2025 at 4:37 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
>>>> [email protected]> wrote:
>>>>
>>>>> Hello Team,
>>>>>
>>>>> Couple of more questions arose during discussion -
>>>>>
>>>>> 1.What all tools should we reopen while restoration? It could be Query
>>>>> tool, ERD, Psql, Schema diff as of now may get additional in future.
>>>>>
>>>>
>>>> Yes :-). Ideally, as much of the original state as possible should be
>>>> restored.
>>>>
>>>
>>> So, should we open the psql without data and schema diff without
>>> comparison results?
>>>
>>
>> I don't see that we have any choice for psql. We absolutely should *not*
>> attempt to automatically re-run user queries.
>>
>> For the schema diff, yes, that could be very expensive. The user can
>> press the button if they want to incur that cost.
>>
>>
>>> Also for the query tools open with an ad-hoc server, should we just open
>>> a query tool with data without connections?
>>>
>>>
>>>>
>>>>> 2.Can we use an existing crypt key to encrypt the query data or simply
>>>>> json encoding should be enough?
>>>>>
>>>>
>>>> We're already storing the query history, so we should follow the
>>>> precedent there.
>>>>
>>> Currently we are storing this data with json encoding done by the
>>> request module.
>>>
>>>
>>>> --
>>>> Dave Page
>>>> pgAdmin: https://www.pgadmin.org
>>>> PostgreSQL: https://www.postgresql.org
>>>> pgEdge: https://www.pgedge.com
>>>>
>>>>
>>
>> --
>> Dave Page
>> pgAdmin: https://www.pgadmin.org
>> PostgreSQL: https://www.postgresql.org
>> pgEdge: https://www.pgedge.com
>>
>>
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: Regarding feature #3319
@ 2025-03-13 11:41 Yogesh Mahajan <[email protected]>
parent: Dave Page <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Yogesh Mahajan @ 2025-03-13 11:41 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
Hi Dave,
Yes, we can store connection info. We might need to tweak how we create the
query tool connections.
Thanks for the inputs.
Thanks,
Yogesh Mahajan
EnterpriseDB
On Thu, Mar 13, 2025 at 5:07 PM Dave Page <[email protected]> wrote:
> Hi
>
> On Thu, 13 Mar 2025 at 11:35, Yogesh Mahajan <
> [email protected]> wrote:
>
>> Hi Dave,
>>
>> What about the query tools opened with an ad-hoc server, should we just
>> open a query tool with data without connections?
>>
>
> Can we not save the connection parameters used in the JSON (excluding the
> password that we can prompt for of course)?
>
>
>>
>> Thanks,
>> Yogesh Mahajan
>> EnterpriseDB
>>
>>
>> On Thu, Mar 13, 2025 at 4:59 PM Dave Page <[email protected]> wrote:
>>
>>> Hi
>>>
>>> On Thu, 13 Mar 2025 at 11:20, Yogesh Mahajan <
>>> [email protected]> wrote:
>>>
>>>> Hi Dave,
>>>>
>>>> Couple of follow up questions -
>>>>
>>>> Thanks,
>>>> Yogesh Mahajan
>>>> EnterpriseDB
>>>>
>>>>
>>>> On Thu, Mar 13, 2025 at 4:37 PM Dave Page <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hello Team,
>>>>>>
>>>>>> Couple of more questions arose during discussion -
>>>>>>
>>>>>> 1.What all tools should we reopen while restoration? It could be
>>>>>> Query tool, ERD, Psql, Schema diff as of now may get additional in future.
>>>>>>
>>>>>
>>>>> Yes :-). Ideally, as much of the original state as possible should be
>>>>> restored.
>>>>>
>>>>
>>>> So, should we open the psql without data and schema diff without
>>>> comparison results?
>>>>
>>>
>>> I don't see that we have any choice for psql. We absolutely should *not*
>>> attempt to automatically re-run user queries.
>>>
>>> For the schema diff, yes, that could be very expensive. The user can
>>> press the button if they want to incur that cost.
>>>
>>>
>>>> Also for the query tools open with an ad-hoc server, should we just
>>>> open a query tool with data without connections?
>>>>
>>>>
>>>>>
>>>>>> 2.Can we use an existing crypt key to encrypt the query data or
>>>>>> simply json encoding should be enough?
>>>>>>
>>>>>
>>>>> We're already storing the query history, so we should follow the
>>>>> precedent there.
>>>>>
>>>> Currently we are storing this data with json encoding done by the
>>>> request module.
>>>>
>>>>
>>>>> --
>>>>> Dave Page
>>>>> pgAdmin: https://www.pgadmin.org
>>>>> PostgreSQL: https://www.postgresql.org
>>>>> pgEdge: https://www.pgedge.com
>>>>>
>>>>>
>>>
>>> --
>>> Dave Page
>>> pgAdmin: https://www.pgadmin.org
>>> PostgreSQL: https://www.postgresql.org
>>> pgEdge: https://www.pgedge.com
>>>
>>>
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2025-03-13 11:41 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-08-12 05:50 Regarding feature #3319 Anil Sahoo <[email protected]>
2024-08-12 08:38 ` Dave Page <[email protected]>
2024-08-12 09:31 ` Anil Sahoo <[email protected]>
2024-08-19 06:09 ` Aditya Toshniwal <[email protected]>
2024-08-20 03:40 ` Anil Sahoo <[email protected]>
2024-08-20 04:44 ` Aditya Toshniwal <[email protected]>
2024-08-28 07:19 ` Anil Sahoo <[email protected]>
2025-01-16 06:37 ` Aditya Toshniwal <[email protected]>
2025-02-19 11:20 ` Yogesh Mahajan <[email protected]>
2025-02-19 11:41 ` Dave Page <[email protected]>
2025-02-19 12:24 ` Yogesh Mahajan <[email protected]>
2025-02-19 13:25 ` Dave Page <[email protected]>
2025-02-19 13:41 ` Anthony DeBarros <[email protected]>
2025-02-20 03:52 ` Aditya Toshniwal <[email protected]>
2025-02-20 09:51 ` Dave Page <[email protected]>
2025-02-20 10:55 ` Aditya Toshniwal <[email protected]>
2025-02-20 11:02 ` Dave Page <[email protected]>
2025-03-11 08:31 ` Yogesh Mahajan <[email protected]>
2025-03-13 11:07 ` Dave Page <[email protected]>
2025-03-13 11:20 ` Yogesh Mahajan <[email protected]>
2025-03-13 11:28 ` Dave Page <[email protected]>
2025-03-13 11:35 ` Yogesh Mahajan <[email protected]>
2025-03-13 11:36 ` Dave Page <[email protected]>
2025-03-13 11:41 ` Yogesh Mahajan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox