Add card position column and always show position in card info #3471
Conversation
rslib/src/storage/sqlite.rs
Outdated
| @@ -205,6 +206,36 @@ fn add_regexp_tags_function(db: &Connection) -> rusqlite::Result<()> { | |||
| ) | |||
| } | |||
|
|
|||
| /// eg. get_original_position(c.due, c.data) -> i64 | |||
| /// Check if c.data contains the position, if not it's still in c.due | |||
| fn add_get_original_position_function(db: &Connection) -> rusqlite::Result<()> { | |||
There was a problem hiding this comment.
Similar routines above all use extract_ in the name; using it here too would be consistent.
I also I think this routine would be better off focusing on returning position | null. The caller can coalesce the returned null value to card.due if they want to fall back on it. That said, do we really want to be doing that? Can't we just leave cards without an original position unsorted?
There was a problem hiding this comment.
The caller can coalesce the returned null value to card.due if they want to fall back on it. That said, do we really want to be doing that? Can't we just leave cards without an original position unsorted?
Unless I'm misunderstanding something, every card will always have an original position. However, the column that stores it will change.
- User makes card, original position is in the due column
- User reviews card, due is replaced with a timestamp of next review and original position is pushed to the data column
It makes senses to fallback to the due column since the original position has to be there if it isn't in data column yet.
How does the user know if the card has an original position or not? Instead of falling back on due if position is unavailable, wouldn't it be clearer to show them separately when they differ? |
Based off my response to your other comment it makes the most sense to display it the same, regardless of the source. I'm assuming our end users don't care what column the original position is being sourced from as long as it is the actual original position. Now if you're aware of edge cases of the original position not existing in the card's data even after first review then I'll have to handle that, but in my testing I didn't see that occurring. |
The use case I'm imagining: the user may have a mix of new and non-new cards, and want to sort them in the order they originally were in, which means sorting based on coalesce(original, current). |
Isn't this what my current implementation does?
|
|
@brishtibheja Do you have any input on the implementation of this? I saw you were on the original thread. I have an idea of what Damien wants but any clarifying details would be helpful. |
|
Added handling of cards without position data, cards that aren't new won't attempt to show the due value as the position. |
|
@taylorobyen I think going forward, we should make a distinction between Also, to remind everyone of the use case brought up in the forums, it was mainly focused on creating shared decks while studying the decks. In such a situation, Lets say I reset all my cards without original position info, what will |
|
So, making the distinction would mean an
A new position is assigned to the card and that position will be shown. |
I simply meant not showing current One thing I'll point out is that the reposition feature should always change the value in As for original due vs current due I think they only differ if you reset all of your cards without |
|
Sorry to keep you waiting, and for not being clear above. Your changes LGTM - thank you! @brishtibheja, I appreciate that some users get confused by due numbers for new cards. But if we take that out of the due column and only show it in the position column, that means the user needs both a due column and a position column to be able to sort all of their cards. We would either want to include position as a default column (taking up more screen space), or users would need to add the column themselves. I think the latter might end up confusing more users than the dual-purpose due column. |
Implements #3336