On Thu, 20 Feb 2025 at 10:56, Aditya Toshniwal < aditya.toshni...@enterprisedb.com> wrote:
> Hi Dave, > > On Thu, Feb 20, 2025 at 3:22 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal < >> aditya.toshni...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan < >>>> yogesh.maha...@enterprisedb.com> wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal < >>>>>> aditya.toshni...@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. >>>>>>> >>>>>> >>>>>> 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
