New answers tagged

0

Your colleague is right. Order by the primary key. The primary key is not devoid of meaning. It identifies each row in the table. It is numeric, which implies the order in which records were created. It doesn't fit perfectly into the terminology of your business domain, but don't overlook the simple and obvious solution for ideological reasons, especially ...


1

Use numeric status values where the higher value represents the higher state. Add that to your index in descending order. Then pull back the result ordered by time stamp and the status in descending order. This way the entry with the farthest progression is always returned.


1

A better approach would be two keep two tables, current and history. The current table would always be the latest update. The other table would be a history table, which would always be just inserts and reads. If you want to get the latest record, query the current table. If your not allowing any dirty reads it will always be the latest record. If you ...


0

It sounds like an event sourcing approach would be helpful here http://martinfowler.com/eaaDev/EventSourcing.html essentially, each time you update the object, you load it, add the event to the history and save everything. When you save the object, you check to see that nothing else has updated the history in the meantime. If they have, you rebuild the ...


0

You are looking for a resource-friendly way to handling this but user-friendly perspective is also a must. I recommend individual requests after each reordered item. Each call allows for you to check if accepted or failed. Failed responses will reset the view and displays an message to the end-user. Accepted requests simple allows continued editing. ...



Top 50 recent answers are included