Option to have the Visual Editing dialogs be modeless dialogs with new connections
If you right mouse click on a Table, View or any other object and choose Create XXX, Alter XXX or XXX Properties it will now option in a Document Tab with the current schema tree connection.
This triggers the actions SchemaTableNew, SchemaTableEdit, SchemaTableView, where <TABLE> is the name of the schema object. The actions for <TABLE> have been modified by Larion to be threaded. We need to propogate this pattern to all other schema objects.
Made change on VIEW's visual edit action handlers (i.e. SchemaViewNew/Edit/View, but NOT SchemaViewDrop) and tested against MySQL, they seemed to be working fine. SVN r28206.
VIEW's implementation is similar to TABLE's implementation but not exactly the same; because in TABLE's implementation, I saw some inconsistency and potential problems (described below).
In addition, using TABLE's implementation, all of Dialog class' constructors need to be modified (it seemed to me that all of Swing related code need to be moved out of Dialog's constructors), VIEW's implementation does not need to modify Dialog's code.
TABLE implementation inconsistency and potential problems:
(1) Validation on Node object, Connection object and ConnectionProperties object:
In the original action handler implementation, if any of objects listed above is null, no action performed and control is returned to caller.
In SchemaTableNew, the validation on these objects follows the implementation of the original action handler.
In SchemaTableView and SchemaTableEdit, if Node object is null, an exception is thrown; if Connection object is null or ConnectionProperties is null, no action taken, execution continues.
(2) Validation on access permission:
In the original action handler implementation, if access permission is denied, a dialog is displayed.
TABLE implementation does the same thing; however, that error dialog is triggered from a non-EDT thread, we'd better avoid this.
(3) Exception handling inside the BackgroundThread:
In TABLE's implementation, when an exception is thrown from the code running inside the BackgroundThread, BackgroundThread simply logs the error to the log file. I think we need to display a dialog to let user know what had happened.
VIEW implementation:
For item (1) above, VIEW implementation follows the original action handler's implementation. If this is not the right way to do it, please let me know.
For item (2) above, VIEW implementation creates the BackgroundThread only if all of validations have passed. Hence, the error dialog is still triggered from inside EDT.
For item (3) above, VIEW implementation will display a dialog from inside the Swing EDT.
Please review r28206 change and let me know your thoughts.
Made change on VIEW's visual edit action handlers (i.e. SchemaViewNew/Edit/View, but NOT SchemaViewDrop) and tested against MySQL, they seemed to be working fine. SVN r28206.
VIEW's implementation is similar to TABLE's implementation but not exactly the same; because in TABLE's implementation, I saw some inconsistency and potential problems (described below).
In addition, using TABLE's implementation, all of Dialog class' constructors need to be modified (it seemed to me that all of Swing related code need to be moved out of Dialog's constructors), VIEW's implementation does not need to modify Dialog's code.
TABLE implementation inconsistency and potential problems:
(1) Validation on Node object, Connection object and ConnectionProperties object:
In the original action handler implementation, if any of objects listed above is null, no action performed and control is returned to caller.
In SchemaTableNew, the validation on these objects follows the implementation of the original action handler.
In SchemaTableView and SchemaTableEdit, if Node object is null, an exception is thrown; if Connection object is null or ConnectionProperties is null, no action taken, execution continues.
(2) Validation on access permission:
In the original action handler implementation, if access permission is denied, a dialog is displayed.
TABLE implementation does the same thing; however, that error dialog is triggered from a non-EDT thread, we'd better avoid this.
(3) Exception handling inside the BackgroundThread:
In TABLE's implementation, when an exception is thrown from the code running inside the BackgroundThread, BackgroundThread simply logs the error to the log file. I think we need to display a dialog to let user know what had happened.
VIEW implementation:
For item (1) above, VIEW implementation follows the original action handler's implementation. If this is not the right way to do it, please let me know.
For item (2) above, VIEW implementation creates the BackgroundThread only if all of validations have passed. Hence, the error dialog is still triggered from inside EDT.
For item (3) above, VIEW implementation will display a dialog from inside the Swing EDT.
Please review r28206 change and let me know your thoughts.
OK, after Tariq logged issue #7252, I looked into TABLE implementation one more time and realized that there is no way to avoid modifying Dialog's code because we wanted to display the 'Connecting...' panel while retrieving database data in the background thread. I will modify VIEW dialog code accordingly.
Modifying dialog constructor code also affects other components, for example: problem logged by issue #7252 which has something to do with how Storage Manager opens a Database Dialog; Database visual edit action handlers as well as Database Dialog constructors have been modified by Larion; the old way to create a Database Dialog in other other components won't work anymore.
OK, after Tariq logged issue #7252, I looked into TABLE implementation one more time and realized that there is no way to avoid modifying Dialog's code because we wanted to display the 'Connecting...' panel while retrieving database data in the background thread. I will modify VIEW dialog code accordingly.
Modifying dialog constructor code also affects other components, for example: problem logged by issue #7252 which has something to do with how Storage Manager opens a Database Dialog; Database visual edit action handlers as well as Database Dialog constructors have been modified by Larion; the old way to create a Database Dialog in other other components won't work anymore.
Here is how a new dialog should behave: When a tab is opened, a 'progress panel' is displayed inside the tab initially. Once all of required data is retrieved from the database, the progress panel is replaced with the real one. The progress panel contains a Cancel button, click the Cancel button will stop the database operation performed in the background and close the tab. If database operation failed, a message dialog will be displayed; the tab will be closed after user closed the message dialog.
In addition to popup menus from the schema tree, visual edit dialogs are also used by many other components. Hence, all of old APIs need to be preserved.
All of objects under the schemagui directory are done:
arraytype, cluster, database, datatype, defaultobject,
function, index, nickname, objecttype, packagebody,
packageobject, procedure, role, rule, schema,
sequence, synonym, table, tabletype, trigger,
user, view.
Here is how a new dialog should behave: When a tab is opened, a 'progress panel' is displayed inside the tab initially. Once all of required data is retrieved from the database, the progress panel is replaced with the real one. The progress panel contains a Cancel button, click the Cancel button will stop the database operation performed in the background and close the tab. If database operation failed, a message dialog will be displayed; the tab will be closed after user closed the message dialog.
In addition to popup menus from the schema tree, visual edit dialogs are also used by many other components. Hence, all of old APIs need to be preserved.
All of objects under the schemagui directory are done:
arraytype, cluster, database, datatype, defaultobject,
function, index, nickname, objecttype, packagebody,
packageobject, procedure, role, rule, schema,
sequence, synonym, table, tabletype, trigger,
user, view.
All of objects under the managegui directory are done, SVN r28291, r28316, r28355,:
alert, archivelog, backup, bufferpool, cache,
controlfile, databasedevice, datafile, dumpdevice, job,
operator, redolog, remoteserver, rollbacksegment, servergroup,
serverprofile, serverrole, serveruser, tablespace,
except
serversession.
The implementation of ServerSessionDialog does not seem to be complete, and, I could not find corresponding nodes in the schema tree either.
All of objects under the managegui directory are done, SVN r28291, r28316, r28355,:
alert, archivelog, backup, bufferpool, cache,
controlfile, databasedevice, datafile, dumpdevice, job,
operator, redolog, remoteserver, rollbacksegment, servergroup,
serverprofile, serverrole, serveruser, tablespace,
except
serversession.
The implementation of ServerSessionDialog does not seem to be complete, and, I could not find corresponding nodes in the schema tree either.
Database dialogs triggered from storage managers are done (MySQL, SQL Server, PostgreSQL, SybaseAnywhere, SybaseASE, SybaseIQ). SVN r28498.
Database dialogs triggered from storage managers are done (MySQL, SQL Server, PostgreSQL, SybaseAnywhere, SybaseASE, SybaseIQ). SVN r28498.
Table dialogs triggered from storage managers are done (MySQL). SVN r28524.
Schema role dialogs triggered from security managers are done (SQLServer, SybaseASE, Informix). SVN r28535.
Schema user dialogs triggered from security managers are done (SQLServer, SybaseASE, Informix). SVN r28537.
Manage alert/job/operator dialogs triggered from the SQL Server Agent are done (SQLServer). SVN r28538.
Table dialogs triggered from storage managers are done (MySQL). SVN r28524.
Schema role dialogs triggered from security managers are done (SQLServer, SybaseASE, Informix). SVN r28535.
Schema user dialogs triggered from security managers are done (SQLServer, SybaseASE, Informix). SVN r28537.
Manage alert/job/operator dialogs triggered from the SQL Server Agent are done (SQLServer). SVN r28538.
The following dialogs triggered from storage/log/rollback-segment managers are done, SVN r28566:
backup - storage manager (sqlserver)
buffer pool - storage manager (db2, db2i, db2z, derby, informix, ncluster, teradata)
cache - storage manager (sybaseAnywhere, sybaseASE)
database device - storage manager (sybaseAnywhere, sybaseASE)
datafile - storage manager (db2, oracle)
dump device - storage manager (sybaseAnywhere, sybaseASE)
redo log group - log manager (oracle)
rollback segment - rollback segment manager (oracle)
tablespace - storage manager (db2, db2i, db2z, derby, informix, ncluster, oracle, postgresql, teradata)
The following dialogs triggered from storage/log/rollback-segment managers are done, SVN r28566:
backup - storage manager (sqlserver)
buffer pool - storage manager (db2, db2i, db2z, derby, informix, ncluster, teradata)
cache - storage manager (sybaseAnywhere, sybaseASE)
database device - storage manager (sybaseAnywhere, sybaseASE)
datafile - storage manager (db2, oracle)
dump device - storage manager (sybaseAnywhere, sybaseASE)
redo log group - log manager (oracle)
rollback segment - rollback segment manager (oracle)
tablespace - storage manager (db2, db2i, db2z, derby, informix, ncluster, oracle, postgresql, teradata)
The following dialogs triggered from security managers are done, SVN r28589:
server profile (oracle)
server group (db2)
server role (sqlserver, sybaseASE, oracle, db2, sybaseIQ, postgreSQL)
server user (sqlserver, sybaseASE, oracle, db2, sybaseIQ, postgreSQL, mysql)
The following dialogs triggered from security managers are done, SVN r28589:
server profile (oracle)
server group (db2)
server role (sqlserver, sybaseASE, oracle, db2, sybaseIQ, postgreSQL)
server user (sqlserver, sybaseASE, oracle, db2, sybaseIQ, postgreSQL, mysql)
There are dialogs embedded in other components and not belong to schemagui and managegui, these dialogs need to be fixed as well.
There are dialogs embedded in other components and not belong to schemagui and managegui, these dialogs need to be fixed as well.
The following dialogs are done:
OraChainDialog, OraClassDialog, OraCreateScheduleDialog, OraCreateWindowDialog, OraProgramDialog.
SVN r28634.
The following dialogs are done:
OraChainDialog, OraClassDialog, OraCreateScheduleDialog, OraCreateWindowDialog, OraProgramDialog.
SVN r28634.
The following dialogs are done:
BackupControlfileDialog, OraJobDialog (Oracle Instance Manager)
LicenseParameterDialog (SybaseIQ Instance Manager)
ParameterDialog (Instance Manager: mssql, sybaseAny, sybaseASE, sybaseIQ)
PinCodeDialog (SGA Manager)
ServerParameterDialog (Instance Manager: MySQL, Oracle)
MssqlAttachDialog, MssqlBackupDatabaseDialog, MssqlDBCCDialog, MssqlRestoreDatabaseDialog (Mssql Storage Manager)
SybaseDBCCDialog, SybaseMoveLogDialog (Sybase Storage Manager)
BackupDatabaseDialog (schema tree Backup node)
JobHistoryDialog (schema tree Job node, SQL Server Agent)
SVN r28673.
The following dialogs are done:
BackupControlfileDialog, OraJobDialog (Oracle Instance Manager)
LicenseParameterDialog (SybaseIQ Instance Manager)
ParameterDialog (Instance Manager: mssql, sybaseAny, sybaseASE, sybaseIQ)
PinCodeDialog (SGA Manager)
ServerParameterDialog (Instance Manager: MySQL, Oracle)
MssqlAttachDialog, MssqlBackupDatabaseDialog, MssqlDBCCDialog, MssqlRestoreDatabaseDialog (Mssql Storage Manager)
SybaseDBCCDialog, SybaseMoveLogDialog (Sybase Storage Manager)
BackupDatabaseDialog (schema tree Backup node)
JobHistoryDialog (schema tree Job node, SQL Server Agent)
SVN r28673.
Object permission related dialogs are done. SVN r28693.
Object permission related dialogs are done. SVN r28693.
Column permission related dialogs are done. SVN r28705.
Column permission related dialogs are done. SVN r28705.
All of dialogs that are derived from the CommonSchemaTab class should be threaded now, except the followings:
Ora9JobDialog - not referenced anywhere
ServerSessionDialog - implementation incomplete?
SybaseBackupDatabaseDialog - implementation incomplete?
SybaseRestoreDatabaseDialog - implementation incomplete?
I did tests on the following servers:
db2, informix, mysql, ncluster, oracle, paraccel, postgresql, sybase anywhere, sybase ase, sybase iq, teradata.
No tests performed on the following servers, I don't have access to these servers:
derby, db2i, db2z, netezza.
All of dialogs that are derived from the CommonSchemaTab class should be threaded now, except the followings:
Ora9JobDialog - not referenced anywhere
ServerSessionDialog - implementation incomplete?
SybaseBackupDatabaseDialog - implementation incomplete?
SybaseRestoreDatabaseDialog - implementation incomplete?
I did tests on the following servers:
db2, informix, mysql, ncluster, oracle, paraccel, postgresql, sybase anywhere, sybase ase, sybase iq, teradata.
No tests performed on the following servers, I don't have access to these servers:
derby, db2i, db2z, netezza.
Issue #938 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build trunk/28705 |
| No time estimate |
If you right mouse click on a Table, View or any other object and choose Create XXX, Alter XXX or XXX Properties it will now option in a Document Tab with the current schema tree connection.
This triggers the actions SchemaTableNew, SchemaTableEdit, SchemaTableView, where <TABLE> is the name of the schema object. The actions for <TABLE> have been modified by Larion to be threaded. We need to propogate this pattern to all other schema objects.