based configuration file from one version to another, and also allows us
to have a single path of creating the table instead of creating tables
using SQLAlchemy or hand rolled SQL
This allows us to run the migrations directly in the code, and it will
avoid the error prone version numbering.
Patched by: Sarah McAlear
Revisions: Joao Pedro De Almeida Pereira, George Gelashvili.
Reviewed by: Ashesh Vashi, Murtuza Zabuawala
Issue:
Changes done by Ashesh in pgAdmin4.py file for setting up PYTHONHOME variable to sys.prefix was applicable only for windows only.
Additionally I have also added exception handling for file provided by user for Backup/Restore/Import/Export.
In order to resolve the non-ascii characters in path (in user directory,
storage path, etc) on windows, we have converted the path into the
short-path, so that - we don't need to deal with the encoding issues
(specially with Python 2).
We've resolved majority of the issues with this patch.
We still need couple issues to resolve after this in the same area.
TODO
* Add better support for non-ascii characters in the database name on
windows with Python 3
* Improve the messages created after the background processes by
different modules (such as Backup, Restore, Import/Export, etc.),
which does not show short-paths, and xml representable characters for
non-ascii characters, when found in the database objects, and the file
PATH.
Fixes#2174, #1797, #2166, #1940
Initial patch by: Surinder Kumar
Reviewed by: Murtuza Zabuawala
Turns out using the config file isn't a good idea if users copy config.py to config_local.py, as it prevents upgrades to the database. This has the added side-effect of simplifying future changes, as you only need to edit 2 files to modify the config DB now, not 3.
inaccessible.
In stand (without threaded) mode, flask application is not able to
process more than one request at a time. Hence - even the client
(browser) send multiple request, when connecting the server (which is
inaccessible), rest of operations get blocked, as making the connection
with the database server is blocking operation.
In order to fix the issue, we're starting the application with thread
support, in which it will create a separate thread of each request.
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).
PostgreSQL node(s).
Browser Tree Node (PostgreSQL object) requires more than just CRUD.
i.e.
- CRUD (Create, Read, Update & Delete)
- Reversed Engineered SQL for the object
- Modified Query in edit mode
i.e. ALTER TABLE ...
- Statistics
- List of dependents
- List of dependencies
- Children node list
This class can be inherited to achieve the different routes for each of
the object types/collections.
OPERATION | URL | Method
---------------+------------------------+--------
List | /obj/[Parent URL]/ | GET
Properties | /obj/[Parent URL]/id | GET
Create | /obj/[Parent URL]/ | POST
Delete | /obj/[Parent URL]/id | DELETE
Update | /obj/[Parent URL]/id | PUT
SQL (Reversed | /sql/[Parent URL]/id | GET
Engineering) |
SQL (Modified | /sql/[Parent URL]/id | POST
Properties) |
Statistics | /stats/[Parent URL]/id | GET
Dependencies | /deps/[Parent URL]/id | GET
Dependents | /deps/[Parent URL]/id | POST
Children Nodes | /nodes/[Parent URL]/id | GET
NOTE:
Parent URL can be seen as the path to identify the particular node.
i.e.
In order to identify the TABLE object, we requires information
about the server -> database -> schema objects.
Hence, the Parent URL for the TABLE object will be something like
this as below:
<int:sid>/<str:database>/<str:schema>
Inherited a new classes ServerGroupView and ServerView, which are
inherited from the NodeView for the implementation of above operations.
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 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.
instead. Add support to the runtime to allow the user to specify the
Python path. This needs to be more automated for release, but will be
useful for debugging and development.
Upon startup, the runtime will attempt to locate pgAdmin4.py in a
number of different relative locations. Once found, it will execute
it in a new thread. The main window is then created and the brower's
initial page is set to the root of the CherryPy server. At present,
that's http://127.0.0.1:8080.
