|
From: Glenn <gw...@co...> - 2002-09-25 15:36:00
|
Folks,
I have a number of suggestions for improving squirrel. Some of these are
based on my previous work on a tool performing this same function, and
some are from my hour or so of playing with squirrel. (Actually, I do
have squirrels that play on my patio and roof, but that's another story. :-)
Since I am new to squirrel, it is entirely possible that I've missed
something that is already in the tool. If so, please let me know.
If I don't hear howls of disagreement, I'll pick some of these and start
working on them.
Glenn
----------------------------------
- Making Connecting to DB easier:
This is a big topic, and my proposals for this would involve major
changes to Squirrel. The explanation of what I would like to do for
this is likely to be lengthy, and possibly controversial, so I'll send a
separate mail devoted to this topic.
- Print the contents of a table:
In my previous tool I had code that would let you print the entire table
contents. It would split large tables appropriately and label the
output pages so you could reassemble them to see the table data on
paper. My guess is that this would work well as a plug-in.
- Edit the data in the table:
The archives mentioned that there were problems with doing this. I saw
only two problems mentioned, and I have proposed solutions to both...
- How to activate/de-activate the feature? My suggestion would be to use
a checkbox in the Session's SQL Preferences. Alternatively, we could
use two radio buttons labeled "Edit in table" and "Read-only".
- Some DBs do not support updateable ResultSets. My solution is to not
use updateable ResultSets at all! In my previous tool, my method of
updating the DB based on changes to the table was to generate an SQL
statement of the form:
UPDATE <table> set <updatedColumn> = <newValue> WHERE
<column1>=<column1Value> AND <column2>=<column2Value> AND ...
This should work correctly except in the case where the DB contains 2
identical rows. To minimize that problem, we may be able to include the
rowID for DBs that support that feature (I vaguely remember that some
DBs do not have that capability). There may also be a problem with
editing BLOBs, CLOBs, and the other binary data types.
Are these solutions acceptable? Are there other problems that I have
not recognized?
- Let Help frame (and others) move external to main frame:
From the way the code is written, I infer that there is some reason for
restricting all of the child windows to fit inside the space of the main
window. However, I find this annoying in a number of cases. For
example, when I get the Help frame, I would like to be able to expand
that and move it in front of or behind the squirrel main frame. Is
there a "human factors" reason for forcing all child windows to be
within the main frame, or can we change this?
- Add a new row to table:
This could be implemented in a couple of ways. We could always include
an empty row at the bottom of the table (as is done in the Postgress
tool named pgaccess). We could have a button that, when the user clicks
on it, creates an empty row in the table, or brings up a separate window
with a blank row in it. There may also be other ways.
The simplest approach from the user's point of view is to always
include an empty row, but that might cause problems in other places in
the code, so we'll need to discuss it.
- Delete a row from the table:
The user should be able to select a row, then click (somewhere) on
"delete" and have that row be deleted from the DB (and the table).
Where should the "delete" button be? One place would be in the menu
that pops up on a right-mouse-button click. I suspect that it should
also be on some more permanent menu, or a tab, or something.
- Page forward/backward through large data sets
This was mentioned in the archives, so I'm just agreeing that I think it
is necessary.
- Help for plugins:
The user should be able to get help on every plugin that is installed.
This could be done in three different ways. One is to include the help
info for all possible plugins in the help file (quickstart.html), but
that would be awkward and not easy to maintain. A second approach would
be to have the main help file somehow automatically reference help pages
in each plugin. The third approach would be for each plugin to add a
button to the Help menu that links to their own help page.
- Plugin version numbers should be visible in the Help menu:
This might be part of the previous feature, or it could be separate.
- Maximum space for table contents:
For some (usually large) tables, I would like to be able to view as much
of the content as possible at one time. This means:
- removing the horizontal space between the main menu ("File", etc.) and
the session window (Note: even if I de-select all toolbars and those
tool bars are removed, the space for them is left in place.)
- possibly removing the title bar on the DB session window, though I'm
not sure about this. For now I think I would keep that one.
- removing the horizontal bar holding the session commands ("Display
Session Properties", etc.)
- removing the tabs for "Objects" and "SQL")
- removing all of the tabs in the data display frame("Info", "Contents",
"Imported Keys", etc.)
- removing the frame containing the tree of tables to view in the DB.
The user should be able to switch into this mode of operation and back
out of it.
To provide access to the various controls ("Object"/"SQL",
"Info"/"Imported Keys"/etc., and the list of tables in the DB) we would
need to provide access to these controls in another place. I would
suggest adding menu items to the main window for "Edit" and "View", and
adding the various controls under those menus.
- Change SQL error message background color:
Yes, the red background makes it clear that this is an error message.
Unfortunately, the bright red makes it hard to read the text of the
error. I don't have an immediate suggestion on how to make this better.
Maybe leave the background white and change the text to:
<red>ERROR:</red> the error message
- Improve performance?:
I don't have specific data to support this, but squirrel seems slow to
me as compared to my old tool (which also used Swing). Since I haven't
seen any comments in the user or developer archives on Squirrel's
performance, it may just be my imagination. If I get some time, I may
do a performance comparison between the two to see if there is some
improvement we can make to Squirrel.
- Include the rowID in the tables for DBs that have it:
I have a hazy recollection that some DBs do not provide the concept of a
rowID. However, for those DBs that do have rowIDs, we should allow the
user to choose to view those rowIDs in the table data. If selected, the
rowID could be displayed in a special column in the table data.
- Use files for binary and large data types:
For BLOBs, CLOBs, and the other binary data types, we could give the
user the option of viewing and editing that data in a temporary file.
This could be useful if the user wants to edit the data or replace it.
For example, if a BLOB is being used to hold a jpeg, then the following
sequence could be used to "edit" that BLOB:
- when the row in the table is read, the BLOB is output to a temporary file
- the table then displays the name of that file
- the user may edit that file, or replace the contents of the file with a
new jpeg.
- Alternatively, we could let the user replace the name of the temp file
in the table with the name of the file containing the new jpeg.
- updating the row in the DB (using the "edit data in table" feature)
then updates the BLOB in the database.
One problem with this scenario is that reading 500 rows from the table
would cause 500 files to be created, which is both extremely slow and
could use a large amount of disk space. An alternative might be to keep
the BLOB/CLOB/etc. in memory and just create the temp file when the user
indicates an interest in editing the data by clicking on that entry in
the table.
This feature could be enabled/disabled in the "Session Properties"
window. We could change the section labeled "Show String Data.." to
something like "Show Data of these types as:" and then for each of the
data types display two radio buttons labeled "String" and "in File".
The following suggestions are of more questionable worth. They may not
be practical or may not be desireable.
- Catch un-caught exceptions in Main:
In the (hopefully unusual) case where we have a bug that throws an
exception somewhere deep in the code, it might be good to catch that
exception and:
- try to log it into the log file
- print a message to the user saying there was in internal problem and
they should email to the development group the log and and explanation
of what they were doing when the exception occured.
The advantages of catching all errors at the top level are that the
program looks better to the user (because it doesn't just dump the
exception stack) and it gives us a chance to capture the exception in a
known place so we can work on it.
- Column width sizing:
The user could set a preference that tables will be initially displayed
with the column widths set to one of the following:
- maximum size of data in the column (this guarantees that all data
(except BLOBs/CLOBs) will be visible in their columns, but with many
tables this will push a lot of columns off-screen to the left, thus
forcing the user to do a lot of sideways scrolling)
- maximum size used (for columns that have a lot of room that is seldom
used, this makes better use of the screen real estate)
- a default size, e.g. 10 characters (this may allow more columns of the
table to be seen
- Let user add and delete columns:
For a completely integrated user experience we should provide for simple
adding and removing of columns in the table view. Adding and deleting
columns would require "Add Column" and "Delete Column" controls
somewhere, possibly under an "Edit" main menu item. Unfortunately, I
believe that this operation may be specific to each DB. I saw notes in
one of DBs (sorry, forget which one) that said "We don't provide the
ALTER TABLE operation, and here is a multi-step sequence of operations
that gives you the same result". We might be able to handle this with
plug-ins. We might also consider providing a default mechanism that
does this in the usual way, but which can be overridden by a plug-in for
a specific DB to do it in a different way.
- Get the list of all Schemas from the DB:
In a former life I worked in an environment where we had multiple DBs on
the same server that was running Oracle. There was a way to log in to
Oracle as a kind of super-user (e.g. as "system" or some such) that let
you list all of the tables in all of the schemas being managed on that
host. Based on that, you could see what the names of the DBs
(actually the DB Schemas) were. That was very handy because we didn't
always remember which schemas were on which machine and what their exact
names were. It would be really nice to be able to point Squirrel at a
machine and say "What Schemas are on that machine?" (Note: this should
not be a big security issue because you still need to know the
user/password to get into and manipulate the DB.) My guess is that we
cannot do this as a general feature, though we might be able to do it
for specific DB engines.
- Create tables:
For creating tables, would it be useful to provide a wizard to help the
user create the table?
My guess is that this would be a low priority feature because creating a
table requires a lot of details from the user that can be entered almost
as easily in the SQL window, though something to help avoid the need to
remember the exact command syntax might be good.
- Manage Users and Passwords:
Should we provide a way to manage Users and Passwords through Squirrel?
My guess is that this is too DB specific, though we might provide a
general interface that gets specialized by DB-specific plugins. I'm a
bit doubtful that this would be worth the effort, but since it is
probably not done often, it might be nice to include in Squirrel (things
that are seldom done are the hardest to remember, and often the most
ugent when they ARE needed, so making those operations easier to do can
be reeeeeealy appreciated.)
- Define a common interface for DB-specific operations:
This idea is kind of "out there". The thought is that there may be
operations that you would like to do on all DBs, but which are
accomplished differently for each one. To support this, we could define
an interface that the main code calls to execute that operation, and the
DB-specific plugins would then do the real work. I think that this is a
little different than the current plugin interface, since that interface
lets you define new operations in Squirrel. The interface that I am
thinking of here would define given DB operations (e.g. "add a column to
a table") that would then be supported or not supported by the
DB-specific plugins.
- Treat foreign keys as links:
We could set up the table entries for foreign keys as links such that
double-clicking on them would take the user to the table containing that
key and displaying the row(s) refered to by that key. We could also
include a "back" feature that would return you to the previous table
view. I'm not sure how useful this would be.
- Graphical representation of tables:
I think I remember a mail in the archives talking about creating a
graphical representation of the tables and their relationships. Is that
work still being persued? It sounds like a really neat idea to me!
- Help with bulk conversions:
When loading a lot of data into a database from another database or from
external files, it would be nice to have a wizard or a graphical tool of
some kind that would help define the mapping of the data from the source
to the DB tables and columns. It would also be nice to have something
to help with DB upgrades when moving from one version of a DB to
another. However, this whole topic is so messy that it may not be worth
the effort to create the necessary tools.
|
