Review page for Database SQL History

This page is used to manage the review of the DatabaseSQLHistory.

The value of this approach is that it allows me to track all the issues separately and to drive them to resolution. For me email reviews although nice and informal are almost impossible to track to conclusion. Inline comments to the main document muddy up the document and are also difficult to track to conclusion.

The review process works like this:

  • Add a comment header of the format "Comment <initials>-<number> (<status>)" (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved
  • If necessary, we do more rounds of discussion until the item is marked as Approved


Commenter Initials Key

  • DVC - David Van Couvering
  • WADE - Wade Chandler
  • JWB - JohnBaker


Recall a statement that previously executed in this editor.

an edited statement is restored from history and replaces the contents of the SQL editor.

WADE (restated by DVC) the history be available through a "time machine" approach of flipping back and forth through "time" in a single query editor pane (the "history" pane) that shows each SQL command executed. I think that's the beginning of a very interesting UI...

Insert a statement from history in the SQL editor (if a statement is selected then it is replaced)

DVC - We may still want a "list-based" view which shows the first 80 or so characters of a query in your history on one line, so you can quickly go to the right command. Similar to file system browsers where you can switch views from a "list" view to a more visual view of things.

JB - use History list

Schema information

WADE Schema information schema browser which one can inspect the table information more clearly from inside, and then a SQL editor to offer more separation of concern

DVC - The "show table info" we wanted to do for this release was a very quick dump of information about a selected table. In a simple text format it shows all the information you would want to know about a table in gory detail. It's just a very quick way to get your hands on a lot of information. It's not intended to replace a visual layout of tables and that kind of richer schema exploration and management. I think one of James' screen shots gave an example of this.

JB - this is a different feature - Table Info feature



  1. Have what you describe. The sql and result pane as a unit. A SQL file/view has a query view and results view.
  2. In the results view there can be multiple tabs for any given SQL view (query view being where you put in the query and select what to run and results view being where you see the results).

DVC Now multiple queries from the single SQL file/view may be examined without having to bounce back and forth running queries and coming back to where you were. Need another result set to review....create a new result tab, select a query, and run it.

This actually sounds like the "view multiple results" feature I have on the list. Some were wondering why you would ever want this, but I think you provide a great use case - create a query pane with all the various queries you like to run or which are associated with each other, and then select a given query (e.g. by placing your cursor on that statement), choose "Run Statement" and a new result tab shows up (or you can check a checkbox indicating you only want a single result pane that is overwritten each time).

Combine this with the "flip pages back and forth" model for SQL history, and you have some pretty compelling stuff!

WADE so I envision some kind of a tabular/table structure in the history selection view which lets the user mark any history providers they choose. Conversely they may uncheck or unmark a provider to have it not be included.

WADE: That could work. Though maybe Navigator could be hidden by another mode or something as it won't > be very useful, or at least I don't see how, for SQL files. Currently it shows what ever the last

Java file I was editing in...which is just a waste of space.   

JWB : Very good idea to try to use the Navigator space - free real estate. We could foreclose it for SQL Editor.

I considered this early on but then we got in the discussion about adding a tab next to the Results and I forgot.
Too, windows with this information could go where favorites usually shows up, and the user could
open and close it as needed just as favorites is done.

JWB I prefer the Navigator area. It could be used like Favorites but if it resided in the same location as Favorites then I don't think the UI would look consistent - A tree view wouldn't be the right component for History.

WADE It would reflect in the objects and columns tab what ever is selected. Then it will be there and be usable for whatever SQL editor and connection is being used. Basically a single and updated view of the current SQL selection.

JWB - Yes, I agree, this goes along with what I was thinking.

Comments for first draft

DVC01 - Why are we forgetting SQL history when a connection is closed? This seems like it would be really frustrating, if you have to disconnect and reconnect for some reason, or you do it accidentally, and all your history is lost.

JWB01 - or SQL yog , history is cleared, but I see your point. The history could be serialized to file that is stored in the userdir

DVC02 - The term "caching" is confusing, as a cache normally means its a temporary copy of something more permanent. In this case, it's the only copy. I would prefer "saving" to "caching"

JWB02 - If History will be more permanent, serialized then "saving" is more appropriate.

DVC03 - I don't quite get the use case of selecting a SQL statement to be added directly to history. Why would I want to do this? Why not just save the statement if I want to save it?

JWB03 - I think you misunderstood or I didn't describe this clearly. What I meant to say is when a statement is selected in the History list of statements, then this selected statement could be added to the SQL Editor by clicking a button. What's added to History are statements executed from the SQL Editor.

DVC04 - Although I agree that Enable Debug already allows logging of SQL statements run by our wizards, I think it's odd/confusing that the two sets of statements are accessed through very different interfaces/parts of the IDE. Why don't we get rid of Enable Debug and just add wizard SQL to the SQL history?

JWB04 - I don't know which wizard you're referring to here: "Why don't we get rid of Enable Debug and just add wizard SQL to the SQL history"

I see that enable debug should log SQL statements and it might make sense to remove enable debug if that is all the value-add.

DVC05 - From your spec, it's not clear to me where the SQL History window is located. Is it a panel like other panels such as the Navigator and Palette? Is it another tab in the SQL editor? Since it's global to a connection, it seems like it should not be tied to a given editor window.

JWB05 - It's a dialog box described in the UI section. We are short on real estate. Initially, I thought that an extra tab could be added to the Result pane but that might look ugly.

DVC06 - Wouldn't it make more sense to allow you to select a connection from the SQL window? This way you don't have to have a SQL editor open to view the SQL history, and the history is not implicitly tied to a particular editor window (you are specifically making this "global" history, versus


DVC07 - I think Wade's comments are worth consideration: I would like to be able to see *all* history for *all* connections or, alternately, see history for a selected connection.

JWB07 DVC08 - I also like Wade's idea of having a matchbox that lets you filter history for specific statements that match the string in the matchbox.

DVC09 - The SQL history should survive a restart of NetBeans

DVC10 - We should have a maximum number of statements saved per connection. This maximum should be configurable.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo