|
|
This project provides access to objects defined in the Database Explorer. Documentation is available in the Javadoc.
Question (arch-overall): Describe the overall architecture. Answer:The Database Explorer module provides the DatabaseExplorerAPI which allows access to the database connections and drivers defined in the Database Explorer. It allows a client to retrieve the connection list and their properties and to create new connections. The Database Explorer also manages a list of JDBC drivers used to connect to databases. The API provides access to these drivers and allows to create new and remove existing drivers.
The DatabaseExplorerAPILookup allows for the declarative registration of database connections and JDBC drivers in the module layer. Database runtimes (which are representations of an instance of a database server) can also be registered in the layer.
Question (arch-usecases): Describe the main use cases of the new API. Who will use it under what circumstances? What kind of code would typically need to be written to use the module? Answer:An external module can register JDBC drivers. A typical example is a module which provides integration with a database server. In this case the module contains the JDBC driver for that database server and uses the Database Explorer API to add it do the Database Explorer.
Another client of this API could be a module providing integration with a J2EE application server. Sometimes a J2EE application server bundles a database server for improving the out-of-the-box experience. When the server is registered in the IDE the JDBC drivers for the bundled database server are added to the Database Explorer.
The drivers are registered either by adding their XML descriptions to the module layer or by making calls on JDBCDriverManager.
When creating a new connection the JDBC driver which it should use can be specified. A list of all the registered JDBC drivers can be retrieved using JDBCDriverManager.getDrivers().
An external module can register new database runtimes. A database runtime is an abstraction of a database server instance (usually bundled with the IDE, an integration module or with a J2EE server). It allows a database server instance to be started and stopped when a connection to this instance is made in the IDE. Database runtimes are represented by the DatabaseRuntime SPI interface and are registered in the module layer.
A module can create new database connections (for example to a bundled database). New connections are added by calling DatabaseConnection.create() to create a new DatabaseConnection instance and then ConnectionManager.addConnection() to add the connection to the Database Explorer.
Sometimes the list of connections needs to be displayed somewhere else in the IDE than the Runtime tab. A typical example is the SQL Editor, which allows the user to select the database connection which the SQL statement will be executed against in a combo box in the editor toolbar. The list of connections can be obtained by calling ConnectionManager.getConnections(), which returns an array of DatabaseConnection instances.
The client usually needs to show the display name of the connection. The display name can be retrieved using the DatabaseConnection.getDisplayName() method.
Sometimes a client needs to retrieve the connection properties, such as the driver class.
An example could be a module for a J2EE server creating a connection pool. The properties can
be retrieved using the getDriverClass(), getConnectionUrl(),
getSchema(), getUser() and getPassword()
methods of the
DatabaseConnection
class.
Usually when displaying a list of connections (usually in a combo box), the last item is "Add Connection", which displays the standard Add Connection dialog of the Database Explorer. This can be achieved by calling ConnectionManager.showAddConnectionDialog().
A component which provides database functionality (such as the SQL Editor)
will need to connect to a database. This can be achieved using the
DatabaseConnection.showConnectionDialog()
method and the java.sql.Connection instance can be retrieved using the
getJDBCConnection()
method.
Most code is already written. About 5 man-days are still needed for the registration of database runtimes and cleanups and about two weeks shall be spent writing tests. The milestone by which this API should be stable is promo-G.
Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? Answer:All Javadoc-specified functionality should be covered by unit tests.
Question (arch-where): Where one can find sources for your module? Answer:
The sources for the module are in NetBeans CVS in db directory.
Lookup - JDBC drivers and database runtimes are registered in the default lookup.
org.openide.actions - Needed in the Database Explorer UI.
org.openide.filesystems - Neded for writing JDBC driver registration files.
org.openide.util - Multiple usages (bundles, request processor).
org.openide.modules - For installing a ModuleInstall.close() method which disconnects the connected connections upon IDE shutdown.
org.openide.nodes - Needed in the Database Explorer UI.
org.openide.dialogs - Needed in the Database Explorer UI.
org.openide.options - Various settings of the Database Explorer, including the list of connections, are saved using a SystemOption.
org.openide.windows - Needed in the Database Explorer UI (the Execute Command top component).
org.openide.loaders - Neded for writing JDBC driver registration files.
org.netbeans.api.progress - Needed in the Database Explorer UI.
Default answer to this question is:
These modules are required in project.xml file:
None.
Question (dep-platform): On which platforms does your module run? Does it run in the same way on each? Answer:No known platform dependencies.
Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? Answer:The module runs on JRE 1.4 and higher.
Question (dep-jrejdk): Do you require the JDK or is the JRE enough? Answer:JRE is enough.
There are two JAR files: the module JAR file modules/org-netbeans-modules-db.jar and a library used by the module located at modules/ext/ddl.jar.
Question (deploy-nbm): Can you deploy an NBM via the Update Center? Answer:Yes.
Question (deploy-shared): Do you need to be installed in the shared location only, or in the user directory only, or can your module be installed anywhere? Answer:Anywhere.
Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public? Answer:Only API and SPI packages are exported.
Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one? Answer:OpenIDE-Module-Module-Dependencies: org.netbeans.modules.db/0 > 1.0
Yes.
Question (compat-standards): Does the module implement or define any standards? Is the implementation exact or does it deviate somehow? Answer:No.
Question (compat-version): Can your module coexist with earlier and future versions of itself? Can you correctly read all old settings? Will future versions be able to read your current settings? Can you read or politely ignore settings stored by a future version? Answer:The module can read old settings, but doesn't store version numbers.
java.io.File directly?
Answer:
No.
Question (resources-layer): Does your module provide own layer? Does it create any files or folders in it? What it is trying to communicate by that and with which components? Answer:Yes. The module contains a standard layer which describes menu items, actions and services. The folders Databases/Connections, Databases/JDBCDrivers and Databases/Runtimes, where database connections, JDBC drivers and database runtimes are registered, are created.
Question (resources-read): Does your module read any resources from layers? For what purpose? Answer:Only resources registered by this module are read.
Question (resources-mask): Does your module mask/hide/override any resources provided by other modules in their layers? Answer:No.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
FolderLookup is used to locate database runtimes. The
Databases/Runtimes folder in the default filesystem is searched for implementations
of the DatabaseRuntime interface.
No.
Question (lookup-remove): Do you remove entries of other modules from lookup? Answer:No.
System.getProperty) property?
Answer:
No.
Question (exec-component): Is execution of your code influenced by any (string) property of any of your components? Answer:No.
Question (exec-ant-tasks): Do you define or register any ant tasks that other can use? Answer:No.
Question (exec-classloader): Does your code create its own class loader(s)? Answer:A class loader is created for loading JDBC drivers.
Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer:No.
Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer:No.
Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer:No. Database runtime implementations could execute such actions though (especially executing external scripts which start/stop a database server).
Question (exec-introspection): Does your module use any kind of runtime type information (instanceof,
work with java.lang.Class, etc.)?
Answer:
No.
Question (exec-threading): What threading models, if any, does your module adhere to? Answer:The API is thread-safe. The methods are not required to run on the event queue (although the implementation of methods which display an UI switches to the event thread where necessary). Events are fired synchronously.
Question (security-policy): Does your functionality require modifications to the standard policy file? Answer:No.
Question (security-grant): Does your code grant additional rights to some other code? Answer:No.
The database connections, JDBC drivers and database runtimes are saved as XML files whose DTDs are published.
Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop? Answer:None.
Question (format-clipboard): Which data flavors (if any) does your code read from or insert to the clipboard (by access to clipboard on means calling methods onjava.awt.datatransfer.Transferable?
Answer:
Implementations of PasteType representing database tables and indexes are placed on the clipboard.
No.
Question (perf-exit): Does your module run any code on exit? Answer:Yes. The connected database connections are disconnected.
Question (perf-scale): Which external criteria influence the performance of your program (size of file in editor, number of files in menu, in source directory, etc.) and how well your code scales? Answer:Performance scales linearly with the number of connections and drivers, but usually the numbers are small.
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer:None known.
Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:A small amount of memory is necessary for the database connections, drivers and runtimes. The amount of memory needed for displaying the structure of a database is directly proportional to the number of elements in the database.
Question (perf-wakeup): Does any piece of your code wake up periodically and do something even when the system is otherwise idle (no user interaction)? Answer:No.
Question (perf-progress): Does your module execute any long-running tasks? Answer:Yes, any database call can be a long-running task. However, these calls are not executed in the event thread.
Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas? Answer:No.
Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic? Answer:No.
Question (perf-spi): How the performance of the plugged in code will be enforced? Answer:Some methods of the database runtimes may take a long time (especially the start method). These methods are never called in the event thread and a progress dialog is displayed.
Built on August 16 2005. | Portions Copyright 1997-2005 Sun Microsystems, Inc. All rights reserved.