eibhearPublic/enode
1
0
Fork 0
Code Issues 1 Pull requests Releases Wiki Activity

Correcting

Browse source
This commit is contained in:
Éibhear Ó hAnluain 2016-10-05 21:25:05 +01:00
parent 2f7fce7982
commit b99b56dd68
1 changed files with 347 additions and 324 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

671
README.md
View file

@ -1,328 +1,351 @@
ENODE: ENODE is Not an Oracle Development Environment
A package and 'mode' for providing an interface for examining and * ENODE: ENODE is Not an Oracle Development Environment
developing for relational databases.
Drawing on TOAD by Quest Software as inspiration, this is provides an emacs A package and 'mode' for providing an interface for examining and
based interface to examine and develop for a relational database. It's developing for relational databases.
hoped that the following databases will ultimately supported:
mysql
postgres
oracle
In fact, the proof-of-concept will be developed for an oracle database,
and as I will have reasonably easy access to mysql and postgres databases,
They will follow suit. I indend to provide high-level interfaces to
databases, so it will be easy to develop a layer for interacting with
databases from other vendors.
Initially, the following functionality will be provided: Drawing on TOAD by Quest Software as inspiration, this is provides
Interface -- look and feel. an emacs based interface to examine and develop for a relational
Connect and disconnect, plus management of saved connection information. database. It's hoped that the following databases will ultimately
Database object listing and examination. supported:
Area for typing of ad hoc SQL statements. - mysql
Presentation of SQL query output. - postgres
- There'll be no facility to change data as presented from a query. - oracle
However, update, delete and insert commands will be facilitated
through the SQL area.
Interface -- look and feel. In fact, the proof-of-concept will be developed for an oracle
The emacs frame will be divided into three windows: database, and as I will have reasonably easy access to mysql and
- The 'object list' or 'navigator' window. postgres databases, They will follow suit. I indend to provide
;; + Here will be listed in tree format the various objects that a high-level interfaces to databases, so it will be easy to develop a
;; schema has. Hierarchy will be something like: Schema, objects layer for interacting with databases from other vendors.
;; (tables, views, packages, etc.), columns/indexes (for tables and
;; views) or procedures/functions (for packages), parameters, etc. Initially, the following functionality will be provided:
;; + The user will enter and leave this window by key strokes or - Interface -- look and feel.
;; mouse clicks. - Connect and disconnect, plus management of saved connection
;; + An object is selected by clicking with the middle button or information.
;; hitting return when point is somewhere on its name. Once - Database object listing and examination.
;; selected, information will be presented in the information frame - Area for typing of ad hoc SQL statements.
;; (see below). - Presentation of SQL query output.
;; + As a tree structure will be used, opening and closing of nodes + There'll be no facility to change data as presented from a query.
;; will result from selection of the node as described. Selecting an However, update, delete and insert commands will be facilitated
;; 'open' node will 'close' it and vice versa. through the SQL area.
;; + A node can be closed or opened using the left and right arrow
;; keys. This will not result in selecting the node, therefore ** Interface -- look and feel.
;; preserving the information presented. The emacs frame will be divided into three windows:
;; + This window can present any of a number of buffers. However, each - The 'object list' or 'navigator' window.
;; of these buffers must be of a perticular type (e.g. navigator), + Here will be listed in tree format the various objects that a
;; and will have a local key map specific to its use. Separation of schema has. Hierarchy will be something like: Schema, objects
;; the buffers will facilitate management -- one buffer for tables, (tables, views, packages, etc.), columns/indexes (for tables
;; another for views, etc. and views) or procedures/functions (for packages), parameters,
;; + The top node for each buffer will be the name of the schema owner. etc.
;; + The user can toggle between showing only one schema owner in the + The user will enter and leave this window by key strokes or
;; list or all of them mouse clicks.
;; - The information window. + An object is selected by clicking with the middle button or
;; + This will present information on the item from the navigation hitting return when point is somewhere on its name. Once
;; window that has most recently been selected. selected, information will be presented in the information
;; + The user can navigate to this window by way of key stroke or frame (see below).
;; mouse click. + As a tree structure will be used, opening and closing of nodes
;; + The window will provide a subset of all the information on the will result from selection of the node as described. Selecting
;; object, and a menu to facilitate showing other information. an 'open' node will 'close' it and vice versa.
;; + This window can present any of a number of buffers. There will be + A node can be closed or opened using the left and right arrow
;; a separate buffer type for each type of information being keys. This will not result in selecting the node, therefore
;; displayed (i.e. table columns are presented differently from a preserving the information presented.
;; table's indexes, which is also different from the list of + This window can present any of a number of buffers. However,
;; triggers on the table, etc.) each of these buffers must be of a perticular type
;; - The SQL interaction window. (e.g. navigator), and will have a local key map specific to its
;; + This window will present one of two buffers -- the SQL input use. Separation of the buffers will facilitate management --
;; buffer and the SQL result buffer. one buffer for tables, another for views, etc.
;; + They can both be presented, but at the expense of the other + The top node for each buffer will be the name of the schema
;; windows. owner.
;; + In the SQL input buffer, entering commands will be as simple as + The user can toggle between showing only one schema owner in
;; entering SQL commands in any sql-mode buffer. the list or all of them
;; + Indentation will eventually be based on my preferred indentation - The information window.
;; scheme, as I am the dictator, and not necessarily benevolent. + This will present information on the item from the navigation
;; + Execution of the command will involve typing a key stroke rather window that has most recently been selected.
;; than the RET key as we will want to format the command nicely. + The user can navigate to this window by way of key stroke or
;; + The output buffer will present data in one of two formats: mouse click.
;; > Select commands will present the selected data in grid format. + The window will provide a subset of all the information on the
;; > Other commands will generate output in simply sequential object, and a menu to facilitate showing other information.
;; output format. + This window can present any of a number of buffers. There will
;; - Possible arrangements can include: be a separate buffer type for each type of information being
;; + Three windows in two rows. The navigator and information windows displayed (i.e. table columns are presented differently from a
;; in the upper row, the latter being the wider. The SQL interaction table's indexes, which is also different from the list of
;; window being in the lower. The upper row would be the higher. triggers on the table, etc.)
;; + Three windows in two columns. The navigator in the first column, - The SQL interaction window.
;; and the information and SQL interaction windows in the second. + This window will present one of two buffers -- the SQL input
;; The latter column will be the wider and the information window buffer and the SQL result buffer.
;; will be higher than the SQL interaction window. + They can both be presented, but at the expense of the other
;; + Two windows in either columnar or tiered format. The user decides. windows.
;; The windows will be related by function: The navigator and + In the SQL input buffer, entering commands will be as simple as
;; information windows together with the latter getting more space; entering SQL commands in any sql-mode buffer.
;; the SQL input and output windows together, each getting equal or + Indentation will eventually be based on my preferred
;; similar space. The SQL window can be displayed in one of the indentation scheme, as I am the dictator, and not necessarily
;; first two configurations if a function is called from the benevolent.
;; information window that warrants it. + Execution of the command will involve typing a key stroke
;; - Help information. rather than the RET key as we will want to format the command
;; + Help can be brought up by typing the '?' key. This will present nicely.
;; the list of key strokes that perform tasks in the window which + The output buffer will present data in one of two formats:
;; has focus. * Select commands will present the selected data in grid
;; + The help display will be presented in the SQL interaction window, format.
;; which will be presented if it isn't already. * Other commands will generate output in simply sequential
;; + If the focus is already in a buffer in the SQL interaction window, output format.
;; the help screen will be presented in the largest visible other - Possible arrangements can include:
;; window. + Three windows in two rows. The navigator and information
;; + Typing the '?' key in the help buffer will replace its contents windows in the upper row, the latter being the wider. The SQL
;; with all the keystrokes possible based on the type of buffer interaction window being in the lower. The upper row would be
;; supported and listing key strokes that work all over ENODE. the higher.
;; + The user can return to the buffer of most recent focus using + Three windows in two columns. The navigator in the first
;; a single key stroke. column, and the information and SQL interaction windows in the
;; + The user can dismiss the help screen and replace the windows to second. The latter column will be the wider and the
;; their previous configuration by typing the 'q' key while in the information window will be higher than the SQL interaction
;; help buffer. window.
;; + Two windows in either columnar or tiered format. The user
;; decides. The windows will be related by function: The
;; Connect and disconnect. navigator and information windows together with the latter
;; - Upon startup, ENODE will ask for connection information in almost getting more space; the SQL input and output windows together,
;; precisely the manner in which sql-.+ asks for it -- using the each getting equal or similar space. The SQL window can be
;; minibuffer to get the username, password and database information. displayed in one of the first two configurations if a function
;; - ENODE will save each connection information in a history file, is called from the information window that warrants it.
;; and will maintain a completion list or lists to facilitate quick - Help information.
;; connection. For connections to new databases, ENODE will ask for + Help can be brought up by typing the '?' key. This will present
;; the type of database (mysql, oracle, etc). This will be stored with the list of key strokes that perform tasks in the window which
;; the connection information. has focus.
;; - The actual commands that will be executed against the database will + The help display will be presented in the SQL interaction
;; be based on the type of database being used. However, this will window, which will be presented if it isn't already.
;; mainly be hidden from the user. + If the focus is already in a buffer in the SQL interaction
;; - ENODE will facilitate concurrent connections. window, the help screen will be presented in the largest
;; - A list of possible connections can be presented in the navigation visible other window.
;; screen. Open connections will be marked. Opening a closed connection + Typing the '?' key in the help buffer will replace its contents
;; involved 'selecting' it. Closing an open connection should not be with all the keystrokes possible based on the type of buffer
;; that easy, and will involve a key stroke followed by an 'Are you supported and listing key strokes that work all over ENODE.
;; sure?' question. Selecting an open connection which is not the + The user can return to the buffer of most recent focus using a
;; current connection makes that connection current. single key stroke.
;; Each connection can be represented in this list either by an alias + The user can dismiss the help screen and replace the windows to
;; given to it explicitly by the user or by a connection string in the their previous configuration by typing the 'q' key while in the
;; format of something like <user>/<database>@<host> help buffer.
;; - Switching between connections will be at the drop of key stroke.
;; + It will be wise to figure out from the start how new connections ** Connect and disconnect.
;; effect the buffers being displayed at the time. - Upon startup, ENODE will ask for connection information in almost
;; + See above regarding switching between connections using the precisely the manner in which sql-.+ asks for it -- using the
;; navigator window. minibuffer to get the username, password and database
;; - Closing connections can be done by one of two means: information.
;; + Close the current connection. Done with a key stroke and a - ENODE will save each connection information in a history file,
;; response to an 'Are you sure?' question, the next connection in and will maintain a completion list or lists to facilitate quick
;; the list of open connections will be activated. If we are closing connection. For connections to new databases, ENODE will ask for
;; the final connection ENODE will report this but not close the the type of database (mysql, oracle, etc). This will be stored
;; application. with the connection information.
;; + Place the point in the connection in the navigator and execute a - The actual commands that will be executed against the database
;; key stroke. will be based on the type of database being used. However, this
;; will mainly be hidden from the user.
;; Database object listing and examination. - ENODE will facilitate concurrent connections.
;; - The most useful window here will be the navigator. It will list the - A list of possible connections can be presented in the navigation
;; objects of interest in a tree structure. There will be separate lists screen. Open connections will be marked. Opening a closed
;; for tables, views, indexes and stored procedure/functions/packages. connection involved 'selecting' it. Closing an open connection
;; tables will drill down to triggers, columns, indexes and constraints. should not be that easy, and will involve a key stroke followed
;; Columns will drill down to triggers, indexes and constraints. by an 'Are you sure?' question. Selecting an open connection
;; Views will drill down similarly. Packages will drill down to specs which is not the current connection makes that connection
;; and bodies. Specs will drill down to types/procedures/functions/etc. current. Each connection can be represented in this list either
;; Bodies will drill down to functions/procedures. Functions/procedures by an alias given to it explicitly by the user or by a connection
;; will drill down to parameter lists and return types (where string in the format of something like <user>/<database>@<host>
;; appropriate). - Switching between connections will be at the drop of key stroke.
;; - The types of information displayed and the information itself will + It will be wise to figure out from the start how new
;; depend on the selected item, examples of which are: connections effect the buffers being displayed at the time.
;; + Tables + See above regarding switching between connections using the
;; > Data navigator window.
;; > Columns - Closing connections can be done by one of two means:
;; > Constraints + Close the current connection. Done with a key stroke and a
;; > Indexes response to an 'Are you sure?' question, the next connection in
;; > Triggers the list of open connections will be activated. If we are
;; + Views closing the final connection ENODE will report this but not
;; > Data close the application.
;; > Columns + Place the point in the connection in the navigator and execute
;; > Source a key stroke.
;; + Constraints
;; > Tables/Columns ** Database object listing and examination.
;; + Packages/procedures/functions - The most useful window here will be the navigator. It will list
;; > Dependancies the objects of interest in a tree structure. There will be
;; > Source separate lists for tables, views, indexes and stored
;; + Triggers procedure/functions/packages. tables will drill down to
;; > Tables triggers, columns, indexes and constraints. Columns will drill
;; > Source down to triggers, indexes and constraints. Views will drill down
;; In the case of views and tables, if we want to see data, it is to be similarly. Packages will drill down to specs and bodies. Specs
;; displayed in the SQL interaction window. will drill down to types/procedures/functions/etc. Bodies will
;; drill down to functions/procedures. Functions/procedures will
;; Area for typing of ad hoc SQL statements. drill down to parameter lists and return types (where
;; - This will display the SQL input buffer. appropriate).
;; - SQL commands can be typed as free text into the buffer. - The types of information displayed and the information itself
;; - Using key strokes, certain actions can then be run on the command in will depend on the selected item, examples of which are:
;; the buffer: execute, parse/compile, explain execution plan, etc. + Tables
;; - Depending on a prefix argument to each of the key strokes commands, * Data
;; they will be executed on the contents of the buffer, the SQL command * Columns
;; the point is currently in or on the commands that are in the region. * Constraints
;; - It will be possible to save the contents to a file. * Indexes
;; - It will be possible to clear the contents in one go. * Triggers
;; - It will be possible to insert the contents of a file, either after + Views
;; point or by first clearing the buffer. * Data
;; - Inserting the contents of the file into the buffer will not mean * Columns
;; visiting the file. That functionality will come later. * Source
;; + Constraints
;; Presentation of SQL (query) output. * Tables/Columns
;; - For commands other than select statements, the output presented will + Packages/procedures/functions
;; be as if the commands had been run on the command line. * Dependancies
;; - Output from queries will be presented in a grid manner, the * Source
;; configuration of which will be decided after some initial testing. + Triggers
;; * Tables
;; Internals * Source
;; - ENODE will maintain many lists which will be used extensively. These In the case of views and tables, if we want to see data, it is to
;; will all be association lists. All the elements of these lists will be be displayed in the SQL interaction window.
;; string values, not symbols. Depending on the case sensitivity of the
;; database system, these will be case sensitive or not. The following ** Area for typing of ad hoc SQL statements.
;; are some of these lists: - This will display the SQL input buffer.
;; + Databases. This list will be populated with the first database we - SQL commands can be typed as free text into the buffer.
;; connect to. The variable describing the current database will - Using key strokes, certain actions can then be run on the command
;; contain a string value from this list. in the buffer: execute, parse/compile, explain execution plan,
;; + Schema owners. There will be a separate list of schema owners etc.
;; per database. As we connect to databases afresh, the first two - Depending on a prefix argument to each of the key strokes
;; elements of this list will be the user we connect as and the commands, they will be executed on the contents of the buffer,
;; system/root schema. The variable describing the current schema the SQL command the point is currently in or on the commands that
;; owner we're connected as will contain an element from this list. are in the region.
;; If the user requests to see any information pertaining to a schema - It will be possible to save the contents to a file.
;; owner (s)he is not connected as, this list is populated fully. - It will be possible to clear the contents in one go.
;; This list can be refreshed by typing the refresh key stroke while - It will be possible to insert the contents of a file, either
;; a schema owner has been selected in the navigation window. after point or by first clearing the buffer.
;; Refreshing the list also refreshes its presentation in the - Inserting the contents of the file into the buffer will not mean
;; navigation window. visiting the file. That functionality will come later.
;; + Tables. There will be a separate list for each owner. This list
;; will be populated for the current schema owner as we connect ** Presentation of SQL (query) output.
;; for the first time. It will be populated for other schema owners - For commands other than select statements, the output presented
;; as we request information on a table owned by that schema owner. will be as if the commands had been run on the command line.
;; This list can be refreshed by typing the refresh key stroke while - Output from queries will be presented in a grid manner, the
;; a table is selected in the navigation window. configuration of which will be decided after some initial
;; + Views. There will be a separate list for each owner. This list testing.
;; will be populated for the current schema owner as we connect for the
;; first time. It will be populated for other schema owners as we ** Internals
;; request information on a view owned by that schema owner. This list - ENODE will maintain many lists which will be used
;; can be refreshed by typing the refresh key stroke while a view is extensively. These will all be association lists. All the
;; selected in the navigation window. elements of these lists will be string values, not
;; + Constraints. symbols. Depending on the case sensitivity of the database
;; + Columns. A list per table or view. system, these will be case sensitive or not. The following are
;; + Indexes. A list per table. some of these lists:
;; + Packages. A list per schema owner. + Databases. This list will be populated with the first database
;; + Procedures. A list per schema owner for non packaged procedures, a we connect to. The variable describing the current database
;; list per package for packaged. will contain a string value from this list.
;; + Functions. A list per schema owner for non packaged functions, a + Schema owners. There will be a separate list of schema owners
;; list per package for packaged. per database. As we connect to databases afresh, the first two
;; elements of this list will be the user we connect as and the
;; - Refreshing a list. system/root schema. The variable describing the current schema
;; The following will happen when a command to refresh a list is called. owner we're connected as will contain an element from this
;; 1. An empty list will be created. list. If the user requests to see any information pertaining
;; 2. The command to populate this new list will be executed. to a schema owner (s)he is not connected as, this list is
;; 3. The contents of the new list will be compared with the existing populated fully. This list can be refreshed by typing the
;; list and newer elements will be added to it. Elements that are refresh key stroke while a schema owner has been selected in
;; in the old list and are missing from the new will be removed from the navigation window. Refreshing the list also refreshes its
;; the old. presentation in the navigation window.
;; 4. If the eode-refresh-recursively variable is non-nil, then + Tables. There will be a separate list for each owner. This list
;; any sublists will also be refreshed. in this manner. will be populated for the current schema owner as we connect
;; 5. Elements of a list that can have a sublist but that sublist for the first time. It will be populated for other schema
;; is nil at the time of the refresh will not have that list owners as we request information on a table owned by that
;; populated. I.e. we don't refresh a list that hasn't been populated schema owner. This list can be refreshed by typing the refresh
;; yet. key stroke while a table is selected in the navigation window.
;; The following will be applied during a list refresh: + Views. There will be a separate list for each owner. This list
;; 1. The node in the navigation list will be 'closed' before the will be populated for the current schema owner as we connect
;; refresh begins. for the first time. It will be populated for other schema
;; 2. The node's parent node will be 'closed'. owners as we request information on a view owned by that schema
;; 3. After the refresh, the parent's node will be opened again. owner. This list can be refreshed by typing the refresh key
;; 4. If the node that had been selected at the time of the call to stroke while a view is selected in the navigation window.
;; refresh exists after the refresh, the point is sent to it and + Constraints.
;; it is explicitly 'selected'. If it doesn't, the node's parent + Columns. A list per table or view.
;; node is 'selected'. + Indexes. A list per table.
;; + Packages. A list per schema owner.
;; - Interacting with the database. + Procedures. A list per schema owner for non packaged
;; + The main engine will be the sql-<engine> functionality that is procedures, a list per package for packaged.
;; provided as standard with GNU/Emacs distributions. + Functions. A list per schema owner for non packaged functions,
;; + All commands will be run in the background and will use the a list per package for packaged.
;; comint-redirect-send-command* functionality.
;; + Lists will be read from temporary buffers. - Refreshing a list.
;; + Presented SQL output will probably have outputting formatting
;; specified for the actual SQL interpreter being used and send to The following will happen when a command to refresh a list is called.
;; the SQL output buffer. 1. An empty list will be created.
;; 2. The command to populate this new list will be executed.
;; - Context. 3. The contents of the new list will be compared with the
;; There will be variables that will maintain: existing list and newer elements will be added to it. Elements
;; + The current database and the most recent one. that are in the old list and are missing from the new will be
;; + The current schema owner and the most recent one. removed from the old.
;; + The current table/view/package/etc. and the most recent one. 4. If the eode-refresh-recursively variable is non-nil, then any
;; There will be a separate pair of variables for each type of sublists will also be refreshed. in this manner.
;; object ENODE supports. 5. Elements of a list that can have a sublist but that sublist is
;; + The current selected item. I.e. There is a table named "FOO" and nil at the time of the refresh will not have that list
;; an index named "BAR". Both the enode-current-table, populated. I.e. we don't refresh a list that hasn't been
;; enode-current-index and enode-selected-item are nil. The populated yet.
;; user navigates to "FOO" in the navigation window and selects it.
;; enode-current-table and enode-selected-item are set to "FOO". The following will be applied during a list refresh:
;; enode-current-index is still nil. The user then navigates to the
;; "BAR" index and selects it. enode-selected-item and 1. The node in the navigation list will be 'closed' before the
;; enode-current-index are set to "BAR", but enode-current-table refresh begins.
;; remains set to "FOO". 2. The node's parent node will be 'closed'.
;; + The previous selected item. 3. After the refresh, the parent's node will be opened again.
;; + The current buffer and the previous one. 4. If the node that had been selected at the time of the call to
;; + The current window and the previous one. refresh exists after the refresh, the point is sent to it and
;; it is explicitly 'selected'. If it doesn't, the node's parent
;; A typical session might be: node is 'selected'.
;; 1. A user calls the command M-x enode.
;; 2. The user is asked to enter a connection string, and is presented with - Interacting with the database.
;; a default which is the most recently used connection. + The main engine will be the sql-<engine> functionality that is
;; 3. The user can accept the default, use M-p and M-n to scroll through provided as standard with GNU/Emacs distributions.
;; a list of saved connections, type in a connection (using completion + All commands will be run in the background and will use the
;; to assist) or type in a new connection name or type in '+'. comint-redirect-send-command* functionality.
;; 4. If the default is accepted that connection string is used to connect. + Lists will be read from temporary buffers.
;; If a connection from the list is entered, it's used. If a connection + Presented SQL output will probably have outputting formatting
;; name that isn't on the list is entered, the user wants to create a specified for the actual SQL interpreter being used and send to
;; new connection with that name. If '+' is entered, the user wants the SQL output buffer.
;; to create a new connection but doesn't know what to call it.
;; 5. If one of the last two, the user is asked for the type of database - Context.
;; we want to connect to.
;; 6. Based on that, the sql-<vendor> function is called and the user is There will be variables that will maintain:
;; then prompted to enter the appropriate information. + The current database and the most recent one.
;; 7. Once connected, the windows are initialised based on the user's + The current schema owner and the most recent one.
;; customisation. + The current table/view/package/etc. and the most recent one.
;; 8. The list of databases is initialised. The current database is set. There will be a separate pair of variables for each type of
;; 9. The list of schema owners is initialised. If the user prefers to see object ENODE supports.
;; all the schema owners in the navigation window at once, this list is + The current selected item. I.e. There is a table named "FOO"
;; populated with all the schema owners in the database. If not, this and an index named "BAR". Both the enode-current-table,
;; list is initialised to the requested schema owner and the enode-current-index and enode-selected-item are nil. The user
;; system/root user. The current schema owner is set. navigates to "FOO" in the navigation window and selects it.
;; 10. The point is brought to the schema owner and the information for enode-current-table and enode-selected-item are set to "FOO".
;; that user is presented in the information window. enode-selected-item enode-current-index is still nil. The user then navigates to
;; is set. the "BAR" index and selects it. enode-selected-item and
enode-current-index are set to "BAR", but enode-current-table
remains set to "FOO".
+ The previous selected item.
+ The current buffer and the previous one.
+ The current window and the previous one.
** A typical session might be:
1. A user calls the command M-x enode.
2. The user is asked to enter a connection string, and is presented
with a default which is the most recently used connection.
3. The user can accept the default, use M-p and M-n to scroll
through a list of saved connections, type in a connection (using
completion to assist) or type in a new connection name or type
in '+'.
4. If the default is accepted that connection string is used to
connect. If a connection from the list is entered, it's
used. If a connection name that isn't on the list is entered,
the user wants to create a new connection with that name. If '+'
is entered, the user wants to create a new connection but
doesn't know what to call it.
5. If one of the last two, the user is asked for the type of
database we want to connect to.
6. Based on that, the sql-<vendor> function is called and the user
is then prompted to enter the appropriate information.
7. Once connected, the windows are initialised based on the user's
customisation.
8. The list of databases is initialised. The current database is
set.
9. The list of schema owners is initialised. If the user prefers to
see all the schema owners in the navigation window at once, this
list is populated with all the schema owners in the database. If
not, this list is initialised to the requested schema owner and
the system/root user. The current schema owner is set.
10. The point is brought to the schema owner and the information
for that user is presented in the information
window. enode-selected-item is set.