|
From: Thackston R. <r.t...@le...> - 2002-10-04 15:25:36
|
Some comments...
Glenn said,
> Simply put, I won't need to locate the Primary Keys because I will
> always use every column of the row in the WHERE clause, so any columns
> that have been designated as Primary Keys will be included
> automatically. <snip>
Updating of rows should not be done this way (in my opinion). We should
check for primary keys and, if supported, allow the user to update the
record, matching on the primary key. If no primary keys are defined, then
the table is not editable. This would encourage good database design and
ensure reliable results. This seems to be the approach taken by most
commercial tools I have seen.
Glenn said,
> <snip> My suggestion is that when the user clicks
> on a binary field that we pop up a small window containing the value in
> a editable text field and a set of radio buttons that lets the user
> view/edit the data as:
> - bits ("10110011" - I would put spaces between each byte)
> - hex ("B3")
> - octal ("1 7 3" - I'm not sure of the best byte alignment here)
> - ascii (i.e. as the ascii chars for those nybbles)
I suggest when a user tries to edit a binary field, we pop up a window that
prompts the user for the type of binary... bitmap (*.bmp), Word document
(*.doc), Rich text file (*.rtf), etc. Think plug-ins, user-defined list,
etc. The user selects the data type; Squirrel then writes the file to a
temp file and opens the file using a "default editor."
For example...
Bitmap (*.bmp) = C:\Program Files\Accessories\Paint.exe
Word document (*.doc) = C:\Program Files\Office\Word.exe
Rich Text file (*.rtf) = C:\Program Files\OpenOffice\OpenOffice.exe
Raw binary (*.bin) = C:\Program Files\pfe\pfe.exe
...
Glenn said,
> I'd like to toss out another open issue here: Should we consider adding
> an "Undo"/"Redo" mechanism to Squirrel? If so, then editing of the data
> would be one thing that should be tied into that mechanism.
Let the user start and end sessions, maybe? They could, at any time, "undo"
their changes by rolling back an open session.
In fact, if we combine editing and sessions, it could work something like
this...
1. Open a table.
2. Start a session, which makes the table editable (checking for primary
keys).
3. Move around the table making changes, which are written to the DB, but
not committed.
4. Commit or rollback the session (table is no longer editable).
For a step-by-step undo feature, we could build a stack for SQL statements
that mirror each change made (in step 3). Call it anti-SQL :) Triggering
an undo would execute the top item on the stack.
Russell Thackston
|
