Creating or opening databases with Derby 10.7.1.1 fails with a "Database <databaseName> not found" error. This happens when starting jdbcnav with the jdbcnavboot.Boot class, but not when using the jdbcnav.Main class. Why does SneakyClassLoader make a difference? It should be possible to avoid using the custom classloader anyway, by using DriverManager's internal APIs for registering drivers directly. I think that that approach is not officially blessed, but the required methods are public. MultiTableDiff (and maybe other code?) needs to honor case sensitivity in foreign keys. For example, MySQL varchar with UTF-8 is case insensitive by default, so it is possible to have a pk 'foo' referenced by an fk 'FOO'. Currently, this kind of situation can cause script creation to fail. I added string-to-object conversion to ResultSetTableModel,setValueAt(), but that seems wrong, or at least inconsistent; the conversion should be performed by the table cell editing window just before it calls setValueAt(). See ResultSetTableModel.java, lines 274-281. In JavaScript, support printing to files. Printing to the editor is nice but can be deathly slow when generating a lot of output. Multi-screen problem (MS Windows): On startup, JDBC Navigator repositions its main window if it would otherwise be off-screen. This is good, but the test for off-screen-ness does not appear to take multiple monitor setups into account; it insists on repositioning the window if it is entirely on a secondary (non-taskbar) monitor. Doesn't Java offer an API to enumerate monitors? This should be fixed because it is annoying. Also, when this happens, it looks like the part that was moved into the main screen does not get painted, at least initially. That would appear to be a Java bug, but maybe one that isn't hard to work around. Exporting a table to CSV should be scriptable. That would be extremely useful for making tailored snapshots. Indentation in generated SQL scripts is messed up (tab + 2 spaces, 2 tabs + 3 spaces, 4 spaces... WTF?) ResultSetTableModel.commit() and ResultSetTableModel.postCommit() are not efficient. While they do a good job of generating minimal DB traffic, they do so using code that is linear in the total number of cells in the table. It should not be too hard to make it linear in the number of actual edits. For small tables, this doesn't matter too much, but when you're working with tables with millions of cells, editing just a handful of cells and then having to wait several minutes for a Commit to complete is not acceptable. select * from utterance group by... not handled correctly; it's looking for a "where" or end-of-text, and gets thrown by the "group". Need better criterion for finding the end of the "from" clause. When closing a browser window, is the underlying Connection always closed? Might be an idea to report Exceptions that get thrown by Connection.close(). Bringing up a "referenced by" window can start with the wrong rows selected. It appears that jdbcnav does know which rows *should* be selected, since changing the sort order appears to fix the situation. Ergo, it's just that the selection does not get set correctly *initially*. Could have something to do with background loading, or am I trying to set the selection from a background thread or something? Try it with diettv.xml.gz (may have to copy it into a DB first, or just point at the MySQL server at the office). Test case: open FDA_DATA_SOURCE, then right-click on the top left cell, and go to FDA_DATA_SOURCE_LINK. Result: the first 8 rows are selected initially, which is incorrect; changing the source order so that a different column than NDB_No is the sort leader fixes it (simply flipping the asc/desc of NDB_No is not sufficient). UPDATE: The above test case actually works fine on my laptop, but not on the screamingly fast PC at work. Which suggests a race condition. Problems generating an Oracle SQL script from a MySQL database: 1) Non-unique PK names (default name PRIMARY?) 2) Identifiers too long (Oracle has a 30-character limit) 3) Unsupported data types (enum, int, bigint, binary_double(?), decimal unsigned) 4) Generating indexes that match PKs 5) Identifiers that aren't legal in Oracle (USER, COMMENT) 6) BIT: translated to NUMBER(1), which is fine, but the values are printed as "true" and "false" (including the quotes); should print 1 and 0 instead. Need to spend some time thinking about copying tables (or sets of tables) from one db to another without loading everything into memory first. Same for generating SQL update scripts, etc. There are too many ways to represent tables, and the UI and implementation needs to be more uniform and more efficient. Jdbcnav *should* be able to copy even a db like ardb without needing tons of memory, and without making the user work their ass of with CSV files etc... When generating SQL, quote all identifiers. Support Oracle SEQUENCE. When the table in the Table Details window is re-sorted, the row selection is not updated. Support swapping tables to files, so you can start loading ridiculously huge data sets without having to supply impossibly large -Xmx parameters. When generating a populate script, am I still doing linear searches to find matching rows, or am I actually doing something clever like sorting both tables according to their PK, and then using an O(n1+n2) algorithm? In addition to generating scripts, there should also be an option to execute them right away, with the additional option to run them without transactions. The idea being to be able to copy or update databases without ever having to store the generated sql. CSV Import/Export: pluggable filters to support tab-delimited, customizable CSV options (change separator, quotation conventions, etc.), different representations for null values (zero-length string, the word NULL, some other special notation). The PK values used by the 'Select FK Value' command are cached inside the BasicTable object (in the pkValues member), but there's currently no provision for invalidating that cache when the table is modified. The conservative approach would be to run a query *each time* getPKValues() is invoked. Cascaded delete/update: when the user deletes or changes a PK, offer to propagate those changes to related tables. When MemoryMonitor notices that memory is getting low, in addition to showing a warning dialog, it should also pause in-progress table loads. Without this, the low-memory warning may be useless, because a table loading thread may overflow memory before the user even has time to react to the low-memory warning. (For now, at least MemoryMonitor could be useful for diagnosing whether certain problems (flaky table loads?) are due to memory shortages or not). Revisit BLOB/BINARY handling: does it work correctly with MySQL and Transbase? Also, revisit the BIT (bit array) type in PostgreSQL. Would be nice if that were handled in a manner compatible with Transbase's BITS/BITS2 types. When opening multiple table editing windows at the same time, and one or more of them are for tables containing Oracle LONG or LONG RAW columns, the exception "Stream has already been closed" may occur, or the application may freeze completely. To avoid this, you must always open tables containing LONG or LONG RAW columns separately. It would be nice if JDBC Navigator would load such tables separately automagically; this will require (1) a new Table property mustBeLoadedSeparately, plus (2) code in BasicDatabase and JDBCDatabase to load such tables serially (the easiest approach would be to load them first, before opening all the remaining windows; this will require a mechanism whereby the Database can keep track of whether any loads are still in progress). Of course this also affects other tables that might be opened while a background load of a LONG-containing table is in progress; the solution will probably have to be something along the lines of a queue. "Set Password" should make the user type the password twice if it doesn't match any of the existing ones (i.e., if it does not successfully decrypt any encrypted connection configs) -- because that means it's a new password, and there's otherwise the danger that the user could accidentally encrypt all his connection configs using a mistyped password. Progress dialog for Generate Script. Make "Reload Tree", "Clear Cache", and "Remove Orphans" scriptable, so that you can mix the SQL embedding and the JDBCNav functionality in one script -- this could be useful for testing etc. It would be nice if "Reload Tree" and table reloading were done in the background, to avoid freezing the UI. "Reload Tree" on Oracle databases can be particularly slow. TypeSpec should distinguish between LONG and LOB types; also, it should maintain a 'size' property for such types. These changes are mostly relevant for accurate cross-DB SQL script generation, but the 'size' property could also be used to enforce the constraint when editing cells (this should probably also be done for the number and string renderers and editors). Visual schema editor. Graphical query generator and plan optimizer.
Go back.