On Wed, Mar 23, 2016 at 10:15 AM, Dave Page <dp...@pgadmin.org> wrote:
> On Wed, Mar 23, 2016 at 9:04 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > > > > > On Tue, Mar 22, 2016 at 4:11 PM, Dave Page <dp...@pgadmin.org> wrote: > >> > >> Hi > >> > >> On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi > >> <ashesh.va...@enterprisedb.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/
