Re: Server side session management using the SQLite (per session) database

On Wed, Mar 23, 2016 at 10:15 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Wed, Mar 23, 2016 at 9:04 AM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> >
> >
> > On Tue, Mar 22, 2016 at 4:11 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >>
> >> Hi
> >>
> >> On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi
> >> <ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
> >>>
> >>> Hi Dave/team,
> >>>
> >>> As discussed, I have implemented the server side session management
> using
> >>> the SQLite database.
> >>>
> >>> Implementation:
> >>> * It creates/reuses the sqlite database per session.
> >>> * Stores the key (as text)/value (as blob) in the sqlite database.
> >>> * Needs to provide the session directory, where you want to store those
> >>> sessions. If this directory does not exist, it creates the directory
> with
> >>> 700 permission. (Default: <USER_HOME>/.pgadmin/sessions directory.)
> >>> * Also - sets default value for the log file to be stored in the
> >>> '<USER_HOME>/.pgadmin' directory. This will allow us to keep separate
> >>> configuration per user on any operation system, when running through
> >>> runtime.
> >>>
> >>> This implementation uses sqlite as session storage, it may affect
> because
> >>> of explicit file system I/O operation. Though - performance should not
> be a
> >>> big issue, as we're not targeting to support very huge parallel
> sessions.
> >>
> >>
> >> Thanks - applied.
> >>
> >> I assume it's expected at this point that new connections still fail if
> >> the backend is restarted (that would come with graceful reconnections)?
> >>
> >
> >
> >
> > Heh, does this actually make sqlite a dependency for pgadmin4? That's
> kind
> > of hilarious :)
>
> It's actually been there for ages - we just now store session info in
> it as well as config settings.
>

Ha. That's what I get for not tracking the development properly.

> > Not saying it's wrong, absolutely not. Just expect a few laughs coming
> off
> > that one :D
>
> I'm aware of the irony :-). It's a perfectly fine embedded database
> though, and that's what we needed here. Running a Postgres instance
> for this is severe overkill - but I don't need to explain that to you.
>
>
Oh, I fully agree with that :) It's just funny.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/