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

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