|
From: Johan C. <jco...@j-...> - 2002-09-26 09:50:57
|
What do you mean with making connection easier? I think that squirrel does this very very nice.
For editing tables i preffer something else (what i also see in other tools)
I dont like direct editting in a table.
you have a table where you can select a row.
That row is loaded in a panel with:
[label] [value]
[label] [value]
and if possible FK are know and the value is showed in a combobox with the list
filled by the pk table, Then i need some info what columns you store
This feature i have pretty much working for another project, but it uses some different
code underneath (i didn't have to generated sql ect because we use OJB)
generating such update statement (PreparedStatements) is a nice idee.
The best would be if getPrimaryKeys works for that jdbc driver.
new is then also pretty easy because you can push the new button and start
typing youre data in the panel.
delete key should be added to the table as a column yes.
printing: You can export it as html and print that....
But maybe it would be nice if printing was directly made in squirrel.
about space for the resultset: Why aren't you just Extracting the resultset
panel?? See the icon (looks like an arrow) on the left top of a resultset panel
then you have what you want a result set maximized in one internalframe.
So i disagree with all youre removemets. (And i don't want to have them
in the menu's (tabs) because i never use menu's)
Performance: This is i thing because we use internal frames.
What i really want is to make squirrel a Eclipse plugin (written in SWT) :)
Driver and Alias are then seperate views. And the SessionScreen is then a Editor
So shown in the editer area.
Altering tables are pretty nasty to do yes.
Maybe we have to make a plugin that defines for as much as possible databases
some templates (velocity?) so that every database can give a template for
all the things they support.
alter table &tablename drop column &column
ect.
But you have some nice idee's of course. So start implementing :))
johan
----- Original Message -----
From: "Glenn" <gw...@co...>
To: <squ...@li...>
Sent: Wednesday, September 25, 2002 5:39 PM
Subject: [Squirrel-sql-develop] Suggestions for improving Squirrel
> 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.
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
|
