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. > > On Wed, Aug 28, 2024 at 12:50 PM Anil Sahoo <anil.sa...@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 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 < >> aditya.toshni...@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 AM Anil Sahoo <anil.sa...@enterprisedb.com> >>> 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 < >>>> aditya.toshni...@enterprisedb.com> wrote: >>>> >>>>> Hi Anil, >>>>> >>>>> On Mon, Aug 12, 2024 at 3:02 PM Anil Sahoo < >>>>> anil.sa...@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 >>>>>> -- >>>>>> >>>>>> <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 <dp...@pgadmin.org> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 12 Aug 2024 at 06:50, Anil Sahoo < >>>>>>> anil.sa...@enterprisedb.com> 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
