JDBC Navigator TODO

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.