Repository navigation
[Suggestion] Warn when copying row id column? #1094
Description
Details for the issue
I guess this should be more in a Wiki page than in the application, but its a weird issue, and users aren't going to find/look for it on the Wiki. Thought I'd mention it here first before creating a Wiki entry...
When copying rows of data (for duplication), it might be common practice to select the rows via using the number column (not necessarily the row_id column, which is usually hidden).
However, when doing this, this copies the row_id column, which means you can't paste it into new cells (as the range is now mismatched - clipboard contains the hidden column which may or may not be what you've selected to paste into)
If you do select the rows using the same method as copying, DB4S obviously moans at each paste, as it can't paste the row_id column.
If you've pasted 100 records, you're in for a bad time clicking that dialog box! ;)
If you just paste into an empty cell, then the row_id is pasted, which isn't what you want, if the row_id column is hidden.
This is all database-dependant and 'depends on what the user clicks on', but I think if the row_id column is hidden (default) and the user has selected rows via the number column, then when they copy cells, DB4S should say, "The row_id column has also been copied. This may cause issues if you attempt to paste it back into DB4S" or some such warning.
Copying the row_id might be useful/required, but not if you're wanting to paste it back into DB4S.
Useful extra information
I'm opening this issue because:
- DB4S is crashing
- DB4S has a bug
- DB4S needs a feature
- DB4S has another problem
I'm using DB4S on:
- Windows: ( version: ___ )
- Linux: ( distro: ___ )
- Mac OS: ( version: ___ )
- Other: ___
I'm using DB4S version:
- 3.10.0
- 3.9.200-beta*
- 3.9.1
- Other: ___
I have also:
- Tried out the latest nightly version: https://github.com/sqlitebrowser/sqlitebrowser#nightly-builds
- Searched for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20
Activity
justinclift commentedon Aug 21, 2017
Thanks @chrisjlocke. Yep, that seems (to me) more like a bug than anything. As you point out, it's pretty much an (unintended) consequence of how we're treating rowid column data.
We should definitely be able to figure out the problem areas around this though, and add appropriate handling so it "just works" the way it's expected to from a users's point of view. 😄
chrisjlocke commentedon Aug 21, 2017
Yes, that's why I put, "depends on what the user clicks on" and what they want to do. Depends if they want that column or not. Guess it shouldn't copy it if it's hidden... That would make sense.
Pasting with the row id is going to cause problems though, but again, also depends on the database schema. Not an easy issue.
Maybe a "play it safe" mode which can be overridden.
sky5walk commentedon Dec 3, 2017
I think it is confusing to copy hidden columns, even though rowid is shown if user selects entire grid.
This should not be the default action, but require a [RightMouse Button Click] or preference setting.
Don't copy data from hidden columns to clipboard
MKleusberg commentedon Dec 4, 2017
Sorry, I somehow misses this issue before. It should be fixed in the next nightly build though. We're now always only copying data from columns which aren't hidden. I think that's the most intuitive way to handle this because it never copies data you don't see and/or you don't have explicitly selected.
Can you give it a try and see if it's working as expected for you? 😄
justinclift commentedon Dec 6, 2017
@MKleusberg Just tested this out now with the latest nightly build on OSX. It's mostly working well now (with one exception). eg if I select a group of rows using the left most numbered column, and then paste that to a new position it "just works".
The exception to this is when there is (say) a BLOB (eg a jpeg) in one of the data fields, and I paste to a row with already existing data (all text values). This error is displayed, and the paste fails:
Any ideas? 😄
sky5walk commentedon Dec 6, 2017
Wow, I very much appreciate dropping hidden columns from the clipboard. :)
To your paste question: Do users really paste multiple blobs?
I would think that requires complex logic to determine where a single blob starts and ends within the clipboard? How would a user build a clipboard with multiple blobs if not originating with DB Browser?
I think the current error is a good placeholder to signal complex data operation to the user.
justinclift commentedon Dec 6, 2017
Errr... not seeing why it should make a difference? From a user's perspective, if they have a bunch of cells with data in them and do "copy"... why would the data type make a difference when doing the "paste" bits? It should "just work". 😄
That being said... I'm saying that with no real idea of our clipboard implementation details, so you could be correct about it being a pain to get working correctly. No idea personally. 😄
mgrojo commentedon Dec 6, 2017
I've noticed another issue from ignoring the hidden columns in the copy operation. Previously both copy and paste took the hidden columns into account. In the following scenario, the user would get now inconsistent behaviour:
mgrojo commentedon Dec 6, 2017
Maybe we should only ignore the hidden rowid column? Or avoid pasting over hidden columns? Spreadsheets always copy and paste hidden columns (sometimes that has taken me by surprise, specially if I hadn't hidden the column myself in a shared spreadsheet file).
sky5walk commentedon Dec 6, 2017
Yes, I think ignoring
_rowid_is a good idea and less confusing to the user.MKleusberg commentedon Dec 7, 2017
Good point. Mimicking the behaviour of spreadsheet applications is probably the best way then. The alternative would be to also ignore hidden columns when pasting. Let's leave this open for a day or two. If nobody needs to ignore all hidden columns (rowid + other hidden ones) I'll change it to only ignore the rowid column (unless it's visible).
justinclift commentedon Dec 7, 2017
When doing a copy operation if we include metadata (eg "column name", "hidden?") with the column data would that be useful for then matching the paste columns? If the paste target has the same columns hidden as the source, then we could also paste the hidden column values.
Not sure if that would be worth the extra effort though. 😄
MKleusberg commentedon Dec 7, 2017
It would certainly be an extra effort but nothing impossible. However, I think it would make it really difficult to comprehend what's going on because then we have implemented both approaches and switch between them depending on the column names and visibilities. I imagine it to be relatively easy to remember that the application either copies and pastes 1) always all columns (well, except for the rowid column) or 2) always only the visible columns. Everything else would require you to remember both behaviours as well as a rule on when to switch between them.
Not sure if that makes sense though 😄 But either way, your approach would also mean to always copy all data even that of hidden columns. The main part of the logic will be on the pasting side. So, copying all columns would be the way to go here, right?
justinclift commentedon Dec 7, 2017
Yeah, that's my worry too. It sounds like a recipe for creating new and weird bugs. 😦
In other issue # communication (don't remember which one), you mentioned maybe we should drop the internal buffer and just use the external clipboard.
That itself sounds like it would simplify things. Maybe we should think of this in those terms and see what looks to be the correct solution from that point of view?
Am unsure if we could add hidden columns and their metadata to the external clipboard in a way that works well. 😄
mgrojo commentedon Oct 12, 2018
I add here a note about something I just detected, so it is not forgotten. The "Copy with Headers" option is incoherent with the cells: for the headers we aren't filtering the hidden columns and for the cells we are. The resulting table has of course a bad format.
sky5walk commentedon Oct 12, 2018
Good catch!
I never tried the "non rowid" hide columns feature until now.
"Copy with Headers" puts all columns in the clipboard.