Made backend changes for:
* Taking care of the connection status in the psycopg2 driver. And, when
the connection is lost, it throws a exception with 503 http status
message, and connection lost information in it.
* Allowing the flask application to propagate the exceptions even in the
release mode.
* Utilising the existing password (while reconnection, if not
disconnected explicitly).
* Introduced a new ajax response message 'service_unavailable' (http
status code: 503), which suggests temporary service unavailable.
Client (front-end) changes:
* To handle the connection lost of a database server for different
operations by generating proper events, and handle them properly.
Removed the connection status check code from different nodes, so that
- it generates the proper exception, when accessing the non-alive
connection.
Fixes#1387
return correct information from a script, but works well on interactive
shell. Used a more proper check for Python > 2 instead of the current
implementation.
Thanks Vishal for the report.
optimized to work from multiple threads. It has too many frequent
transaction from multiple threads, and that tends to result into the
'database is locked' error of sqlite.
With the new implemenation, we're using the caching mechanism, which
keep the data in the memory all the time, and saves it on request
completion, and loads it only for the first time. Also, it will storage
the data using pickle, which will be faster than accessing sqlite.
Fixes#1329
selection, creation, upload/download files/directories resides on the
server side.
This will be useful for file selection/creation for different server
side utilites like pg_dump, pg_dumpall, pg_restore.
There are times, a module is loaded multiple times, and returns same set
of CSS files mulitple times, in order to avoid loading the same file
multiple times, we will create a set out of the list of CSS files.
required by its javascript module.
This will allow us to load the javascript modules as a static file, and
not as a Jinja2 template. This will increase the load time, as it will
decrease number of templates to be processed during loading those
javascripts.
While accessing the configuration database from multiple session, it
results in to the error - OperationError, because - sqlite locks all the
database, and does not allow to access it simultaneously. We added the
timeout to give some time window for accessing it simultaneously.
DriverRegistry is executed second time.
Also, initialize the driver before registering different blueprints,
which uses those driver inside them.
Thanks Khushboo for reporting the issue.
server connection.
The BaseDriver and BaseConnection are two abstract classes, which allows
us to replace the existing driver with the currently used. The current
implementation supports to connect the PostgreSQL and Postgres Plus
Advanced Server using the psycopg2 driver.
(lazy loading) using the require.js. This allows us to load the
javascript required for any node, only when it was loaded in the browser
tree. Also, introduced the mechanism to show/edit/create of any node in
a tab panel (wcDocker.Panel).
submodules inherited from the PgAdminModule instead of regular
Blueprint. This allows us to load the module automatically from the
under the pgadmin directory, and will work to extend the pgAdmin
extension module.
PgAdminModule is inherited from the Blueprint, and bring several
methods:
- get_own_stylesheets, which returns the stylesheets used by the module
(excluding its submodules stylesheets)
- get_own_javascripts
- menu_items, which returns a dictionray mapping the old hook names
(context_items etc) to a list of MenuItem instances
For more specialized modules (as for now, any module that should be part
of the browser tree construction), one can define an abstract base class
defining additional methods.
For example, the BrowserPluginModule abstract base class defines the
following methods:
- jssnippets
- csssnipeets
- node_type
- get_nodes
This commit adds the following:
- Storage of server groups in the configuration database
- Creation of a default server group on in the database
- A mechanism for plugging in treeview node types
- A node type for server groups with:
- Treeview display
- Custom per-node javascript implementing a menu option/dialogue to add new groups
- Custom per-node CSS to style the treeview node
- JSON formatted data in response to AJAX requests, including:
- Success/failure indication
- Error message
- Extra info (e.g. stack trace)
- The original request data
- Additional return data, e.g. node ID and label etc.
Modules may now include functions that return lists of menu items
that will be included on the main browser window menu. While we're
at it, move the test views into a separate module.
This uses a single default user in the config database, which is
auto-logged into the app when SERVER_MODE = False. In this mode we
also hide/remove user-related functions in the UI.
A user authentication module based on flask-security is added, which
allows users to login and change/recover passwords etc. Custom templates
are included for the user/password UIs.
A new setup script will initialise the user (and later settings) DB,
adding the first user and granting them an Administrator role.
A redirects blueprint module is added to handle simple URL redirects.
A browser module is added and currently renders a skeleton page with
a menu bar, gravatar and jumbotron.
NOTE FOR LATER: Currently this code might make the nice basis for any
web app that needs user management and plugins. Hmmm....
