#12 Editing of table rows.

[Sanjay Madhavan]

very nice plugin.

I suggest that the edit/update of rows could be implemented as editable table rows.
Alternately double clicking on a column could open an editor for the column cell.
The current edit implementation is clumsy/unusable when handling
tables with a large number of columns since the view could exceed the screen size and has no scroll
bars etc.

Also adding a commit/rollback button on the table view would allow multiple edits to be comitted or rolled
back in one operation.

/sanjay

[Tom Schneider]

Logged In: YES
user_id=47435

Sanjay,
I've looked into having editable table, but it's just too
risky using any method I can think of.
I would be interested to know if you have any ideas on how
this can be accomplished without having potentially adverse
side affects. (e.g. updated rows that weren't supposed to
updated, or not updating the correct row)
Tom

[Paul Gross]

Logged In: YES
user_id=1039942

A fairly risk-free way to edit most tables might be as follows:
Detect any table keys (primary key or identity column), and
permit editing only when one is found. If the table doesn't
have a detectable key, flag 'READONLY TABLE - NO PRIMARY
KEY' the on the display. This way the user knows why the
table they are looking at can't be edited, but many tables will
be safely editable.

[Julen Parra]

Logged In: YES
user_id=180901

Yes, that's the principle I'm following in the long-delayed
implementation of this feature. There is however another
step to reasonably take, that is, to use pseudo-columns.
Some databases (Oracle for example) have for every row an
unique identifier, a pseudocolumn (ROWID for Oracle) that
can be used even if the table has no other key. These
pseudo-columns have the risk that can be reused, so if you
do a select, then an update, in the time the row with that
ROWID can be deleted, and its ROWID assigned to another. But
that's highly unlikely, so the use is fairly safe. The use
of pseudo-columns, however, add a degree of complexity to
the implementation of the feature.

As a third step, the user could be allowed to select a
number of columns as the key for updating that table. Those
columns should have to be stored as local metadata (local to
Quantum) for the table. There is now no mechanism in Quantum
to store local metadata for a particular table, and a
complete implementation (solving things like table drops and
so on) can be complex, as more uses can easily be conceived.

Of course, your idea can be used as the solution for a first
release, as it may be better to have something not perfect
that nothing at all, and wait for the perfect implementation.

Another design decision to take is the fact that Eclipse
3.0, if I'm not mistaken, does allow virtual tables to be
defined. That would eliminate the need of limiting the
loaded number of records, but it's obviously another
implementation. As 3.0 is here, perhaps I should do only the
3.0 implementation, and forget about Eclipse 2 users,
probably an endangered species anyhow.

Doubts, doubts, doubts.

Thanks for your ideas :)

[Elvin E. Ebora]

Logged In: YES
user_id=949827
Originator: NO

This issue has already been addressed by the update, insert and delete popup windows.