Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tki8K-006B94-Q8 for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 11:20:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tki8J-007Sp2-C1 for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 11:20:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tki8I-007Sou-W3 for pgadmin-hackers@lists.postgresql.org; Wed, 19 Feb 2025 11:20:51 +0000 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tki8E-001kff-2S for pgadmin-hackers@postgresql.org; Wed, 19 Feb 2025 11:20:49 +0000 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-6fb9dae0125so13517657b3.1 for ; Wed, 19 Feb 2025 03:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1739964044; x=1740568844; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mmSX9Zwi6UkZ3HkH2ATJ0rjiqjyNzCt4EvPUAnCrwz0=; b=fP72xYEcPS+b210EHWfaPktCn0c9CwmvUWPyLHjr/S9T5OOw2KC3lLxqOaq4bj1oMI sKt7bL1g9SKamKZMMOgAj3KT/9L9J4vvoj+P+wlcEMVnkufmOd9QxvreH+kdXfejv8OD Y1KrtYEWodFA1pAYJ2XEh4olUq6dEl49MpDoTFEcIjV/hG/eqih4e23vQdP/KFrT1w3l 6VIweXb6Gj6Cddoetv71hZLu+slOohu8Yvtow8tIs4DWGpEC20zW3AjuzgeDMgO6N/pu RUu3IL1R/JzuRP6HzGxlxdDFpvDfYjb11uHeG9Atg1fsPoTSkpGnzOGg37h0+c8K3RUJ 8X/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739964044; x=1740568844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mmSX9Zwi6UkZ3HkH2ATJ0rjiqjyNzCt4EvPUAnCrwz0=; b=FdTy0bzhoUAnbdpRTgydavwBNVgT6InrfvuCmB+l9282IOQvAGiNauom6vf+MHD2X4 4hgEM9SKdRF0io0tWu5zLJH6bc8AiPL6+3fzptb/8RPvvxvRa1/zHLRSLCgom85DDMVb 7RQQ6Lg9LNGjGC40voCgvUXMWGihNKwNQcPETyzEfMIcxzhnIQRCmkoF4Te5kS5N4TMp JfxTKFHh8ariJTKTcmAVBaS1U2+ftOGUl2IaasKMfQbJ50Rj0jRY8b1BWcb3bSnkmVPW mPf1KFIHZ9pcOtOeVk5kf3fqd0JRC3YZ5mhNI6ipLayCyjF/q1iiLMEkQGG9FTwHMi9H pNKA== X-Gm-Message-State: AOJu0YzS5Bta6rsvefCugVEfNW9vCh0jWvvO/IMUa1m3hzRhsKCVxzq2 Kw+U+kx39I/FCkG1yMbL+BWFpJayKuM1kdSPQ9dVgHtNrOx/T0yf3u105uRz1BPVun92orLmF7l wlbpUPe3pmpA8ymtgzFm8EwHi5Aw9t4VkLjQ2a4aWLPIzZ/3ddg== X-Gm-Gg: ASbGncsjDDMyeKfRaZyCFB+fjlc5pO5SqmYxPqRfoxbCE2IhokA2wPZC0ktxNH/vlKn Njb4N81TVtaJF2V7Cll/5pFppvN9GDsRF6Plm3TI0uDkrEutHUw1sa9xrHr/2RxmGpn7Ouw/7Nm /mMJNMxzhBaa7rp6JnGDyrQJTlwD+A X-Google-Smtp-Source: AGHT+IFW5z/WkzX0ugICRhdOyvA6onB+xdP7jK8KkdIsqKV7OuQD4Yhyi50VgHV3XC5RQM98Eyls0ucig3c2nG5H22g= X-Received: by 2002:a05:690c:3393:b0:6f9:b189:3ccb with SMTP id 00721157ae682-6fba5696362mr31817387b3.17.1739964044230; Wed, 19 Feb 2025 03:20:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yogesh Mahajan Date: Wed, 19 Feb 2025 16:50:07 +0530 X-Gm-Features: AWEUYZnAPTlF0MmMVSYKCdsJgtWgdtQ1RQ5bbwVvJIdFHnTdMK_n6QDII_CAThI Message-ID: Subject: Re: Regarding feature #3319 To: pgadmin-hackers Cc: Dave Page , Aditya Toshniwal Content-Type: multipart/alternative; boundary="000000000000c75c19062e7cf20f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c75c19062e7cf20f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave/Team, Here are 2 storage options - 1.IndexdDB - IndexdDB is supported by all the browsers except IE.(Ref ). 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=E2=80=AFPM Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> 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=E2=80=AFPM Anil Sahoo > 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=E2=80=99s details that are required to make the co= nnection >> 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 ope= n as >> it is and will restore the workspace and connections on query tool ta= bs. >> 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 qu= ery >> 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 i= n the >> database as query history else not. Should we go with storing the wor= kspace >> 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 >> -- >> >> >> >> *Anil Sahoo* >> >> Software Engineer >> >> www.enterprisedb.com >> >> Power to Postgres >> >> >> >> >> >> >> >> On Tue, Aug 20, 2024 at 10:14=E2=80=AFAM Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> 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=E2=80=AFAM Anil Sahoo >>> wrote: >>> >>>> Hi Aditya, >>>> >>>> As we are already storing the query history in the pgAdmin 4's databas= e >>>> 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 >>>> -- >>>> >>>> >>>> >>>> *Anil Sahoo* >>>> >>>> Software Engineer >>>> >>>> www.enterprisedb.com >>>> >>>> Power to Postgres >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 19, 2024 at 11:40=E2=80=AFAM Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Hi Anil, >>>>> >>>>> On Mon, Aug 12, 2024 at 3:02=E2=80=AFPM Anil Sahoo < >>>>> anil.sahoo@enterprisedb.com> 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 >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *Anil Sahoo* >>>>>> >>>>>> Software Engineer >>>>>> >>>>>> www.enterprisedb.com >>>>>> >>>>>> Power to Postgres >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 12, 2024 at 2:08=E2=80=AFPM Dave Page wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo < >>>>>>> anil.sahoo@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Hi Hackers, >>>>>>>> >>>>>>>> >>>>>>>> This feature #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 th= e >>>>>>>> Object explorer tree state but to save the contents of panels we w= ill >>>>>>>> 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 i= s >>>>>>> no way to restore the state of a connection to what it was and be s= ure >>>>>>> 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 workspa= ce 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* >>>>> >>>>> "Don't Complain about Heat, Plant a TREE" >>>>> >>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* >>> >>> "Don't Complain about Heat, Plant a TREE" >>> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* > > "Don't Complain about Heat, Plant a TREE" > --000000000000c75c19062e7cf20f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave/Team,

Here are 2 storage=C2=A0options -=C2=A0
1.IndexdDB= -=C2=A0
IndexdDB =C2=A0is supported=C2=A0by all the browsers except IE.= (Ref)= . Electron also supports it.=C2=A0
Pros -=C2=A0
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=C2= =A0the data.

2.File based -=C2=A0<= /div>
Similar to session files, we can store them in the same pga= dmin data dir.This might add a load to the pgadmin server in case of server= mode.
Pros -=C2=A0
In any mode, data will persist.
Cons -
May introduce l= atency and more load on the pgadmin server as data will be stored at the se= rver side.


Before moving=C2=A0forward, can you please help to ge= t answers for the questions=C2=A0below -=C2=A0
1.Should the= query/workspace data persist in both desktop and server mode?=C2=A0
<= div style=3D"font-family:verdana,sans-serif;font-size:small" class=3D"gmail= _default">

Thanks,
Yogesh Mahajan
= EnterpriseDB


On= Thu, Jan 16, 2025 at 12:07=E2=80=AFPM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com= > wrote:
Hi=C2=A0Anil/Dave,
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">
W= hy not use browser localStorage for saving this information? It persists wh= en the browser closes and is based on the URL. It is safer to store at the = user's machine than on our server.=C2=A0
For Electron also it should wo= rk.
This will reduce load on the pgAdmin server.

On Wed, Aug 28, 2024= at 12:50=E2=80=AFPM Anil Sahoo <anil.sahoo@enterprisedb.com> 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 to= ol
  3. Each connection=E2=80=99s details that are r= equired 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 edito= r 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 belo= w,

  1. For desktop mode the application is opened w= ith some query tools and the user closes the application and on restarts th= e 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 th= is feature.=C2=A0
  2. I came across one issue reported by one user= i.e https://github.com/pgadmi= n-org/pgadmin4/issues/6666, where pgAdmin crashed due to long SQ= L scripts that can be in Megabytes stored as query history.=C2=A0 We fixed it by giving MAX_QUERY_LENGTH=C2=A0 to 1000000, a= nd checking if any query length is below the value then it gets stored in t= he database as query history else not. Should we go with storing the worksp= ace and query tool details in SQLite DB or use a file system to store the d= etails and retrieve the content accordingly?

Please let me know your suggesti= ons on this.

<= /div>
Thanks
Anil
--
<= table style=3D"border:medium;border-collapse:collapse">

Anil Sahoo

<= span style=3D"font-size:13.3333px;white-space:pre-wrap">Software Engineer

www.enterprisedb.com

Power to Postgres

<= a href=3D"https://www.linkedin.com/company/edbpostgres" target=3D"_blank"><= span style=3D"font-size:11pt;font-family:Roboto,sans-serif;color:rgb(17,85,= 204);vertical-align:baseline;white-space:pre-wrap">= =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0



=
On Tue, Aug 20, 2024 at 10:14=E2=80= =AFAM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
=
Hi Anil,

There can be multiple que= ry tools open with large files. Not entirely sure if storing in SQLite DB i= s a good idea.
External databases won't come in the picture as 99.99% u= sers will not use external DB for desktop app. We're only doing this fo= r desktop app.
And also consider the case where a SQL file is opened with s= ome unsaved changes.

On Tue, Aug 20, 2024 at 9:11=E2=80=AFAM Anil Saho= o <anil= .sahoo@enterprisedb.com> wrote:
Hi Aditya,

As we are already storing the query = history in the pgAdmin 4's database file.
I am planning to st= ore the information the same way. That can be an internal database file lik= e SQLite or external database.=C2=A0

Let me kn= ow if you all have any suggestions on this.

Thanks=
Anil
--

=

= =

Anil Sahoo

Software Engineer

www.enterprisedb.com

= Power to= Postgres

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0



On Mon, Aug 19, 2024 at 11:40=E2=80=AFAM Aditya Toshniwal <aditya.toshniw= al@enterprisedb.com> wrote:
Hi=C2=A0Anil,

On Mon, Aug 12, 2024 at 3:02=E2=80=AFPM A= nil Sahoo <anil.sahoo@enterprisedb.com> wrote:
=
Hi,

Yes, We will store the details that are needed = to re-establish the connection.

How/Where are y= ou planning=C2=A0to store the information? Query text could be large.
=

Regards
Anil
=
--
=

On Mon, Aug 12, 2024 at 2:08=E2= =80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Mon, 12 Aug 2024 at 06:50, Anil Sahoo <anil.sahoo@enterprisedb.com> wrote:

Hi Hackers,


This feature=C2=A0#3319, demands the Wor= kspace 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 init= ially 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&= #39;ve got it right. How do you propose to handle that? I assume in a simil= ar way to the warnings we give if a connection has to be re-established?=C2= =A0


We will use debouncing to store the workspace data and all other da= ta related to panels in the pgAdmin 4's configured database file. Throu= gh 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 al= l other panels.


OK.=C2=A0<= /div>

-- =
Dave PagepgAdmin: https://w= ww.pgadmin.org
PostgreSQL: https://www.postgresql.org

PGDay UK 2024, 11th September, Londo= n: https://2024.pgday.= uk/



--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com

--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com

--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"
--000000000000c75c19062e7cf20f--

Anil Sahoo

= Software Engineer<= /span>

<= span style=3D"font-size:10pt;font-family:Arial;color:rgb(9,110,219);backgro= und-color:transparent;font-weight:700;vertical-align:baseline;white-space:p= re-wrap">www.enterprisedb.com

Power to Postgres

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0