-1

I have a DAO that removes rows from a DB table. I have a GUI table representing some of those rows that passes user requests for deletion to that DAO

How should I update the GUI table?

  1. I could attach a listener that listens on successful deletions and deletes a corresponding GUI row on each of them. I'm not 100% comfortable with a DAO registering listeners, tbh. Besides, updating GUI on each deletion may backlog the event queue a bit, I reckon

  2. I could make the DAO return a collection of deleted rows' ids and then iterate over it and delete GUI rows in my widget class. Theoretically, only some of the submitted rows can be successfully deleted, that's why I can't iterate over all submitted ids. I'm inclined to pick this option but have doubts

  3. I can refresh the entire table once everything is over. The table data is not expected to be huge, so this option is tempting for its simplicity. However, I'm not sure I should rely on that as a developer. If the data is big, it's going to be costly

Or, I guess, I could do something else

What is the right approach?

Improve this question
4
  • I think 2 is the best - reacting to those which are recorded as actually deleted - falling back to 3 if necessary.
    – Steve
    CommentedJul 29, 2024 at 14:33
  • 1
    if the user has clicked on a row to delete it, and the delete method hasnt errored, you can just remove the row they clicked on
    – Ewan
    CommentedJul 29, 2024 at 15:31
  • I used to just have an event “database changed”. Plus a method that wouldn’t read an object from the database, but pass an existing object, update it with the contents of the database, returning a Boolean whether there was any change. That was plenty fast on an iPhone 5. With a GUI where every object could have a different height.
    – gnasher729
    CommentedJul 29, 2024 at 16:42
  • 1
    You get around many performance problems if your GUI library has a well - performing class for tables. For example, an iOS table view stores one table view cell per table row that is displayed. Your table may have 200,000 items but only 20 cells on the screen are actually used at any time. The same cells are reused for whatever item they display at the moment.
    – gnasher729
    CommentedAug 1, 2024 at 16:55

2 Answers 2

Reset to default
4

Personally, I'd lean towards #3 - reload the whole thing.

Any kind of "change tracking" runs the Risk of getting of out of step and, eventually, require reconciliation or reloading. As you say, reloading is the simplest solution and will always work.

You're right to be worried about the load time, but then you should also question whether you should be putting that much Data in front of the User. What are they expected to do with it all?

As an aside, if this were a web-based application, your "update" processing would naturally end with a redirect to a "viewer" page that would, itself, reload the data anyway.

Improve this answer
1
  • Thank you. By the way, we have at least one panel where we load a ton of data (it's a tree with ICD entries). It may take a minute to fully load, I figure. Reloading would not be a good approach
    – Sergey Zolotarev
    CommentedAug 30, 2024 at 6:48
2

There is no canonical "right approach." This depends on the requirements you need to implement balanced with the engineering challenges presented by each option. If I have any general advice to give in this situation, it is to experiment. Essentially, you are deciding between a number of possible solutions where the viability of each has yet to be determined. Start with the option that is simplest to implement. Don't go inventing performance problems that you have not measured, especially if the simplest solution gives performance that is good enough for the end user.

There is no empirical methodology here. If you think refreshing the entire table in the GUI is the simplest approach, start with that. If you determine that suits your needs, then you have saved time. If it doesn't suit your needs, then the deficiencies in that solution can be used as a guide when choosing the next option to try, or it might lead you to a fourth solution you hadn't thought of.

Improve this answer
4
  • But shouldn't you, as a professional developer, foresee problems before they arise?
    – Sergey Zolotarev
    CommentedJul 30, 2024 at 4:57
  • 1
    @SergeyZolotarev, foreseeing problems involves predicting the future. So far as I know, humans do not have precognition. Every problem I've "foreseen" has either never come to pass, or the solution ended up being so radically different that it simply wasn't worth the effort. This is a lesson I wished I had learned much earlier in my career. This doesn't cover every problem, of course. Let experience be your guide, but start with the assumption that you cannot predict the future. Best you can do is create a system capable of being changed with confidence.
    – Greg Burghardt
    CommentedJul 30, 2024 at 12:16
  • 1
    @SergeyZolotarev, most problems I "foresee", are just problems I've seen before - and it's very easy in this game to encounter things you haven't seen before. I think Greg's point though is that the circumstances of development can be so different, that there's no one approach that works for all circumstances, and which can therefore answer your question in the abstract. Even when we can state principles, applying those principles often requires a careful judgment about competing principles, calibrated by practical experience and a familiarity of the circumstances of development.
    – Steve
    CommentedJul 30, 2024 at 13:15
  • 1
    @SergeyZolotarev: as a professional developer, I foresee one main problem: overengineering. That happens when people try to solve problems "just in case". Implementing something simple which works and optimize only when needed is the most professional approach I know.
    – Doc Brown
    CommentedAug 3, 2024 at 15:21

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.