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

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

> 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.