You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should IDs be permanent? If not, when does an ID free up?
Imagine you create 5 tasks and mark the first 3 as done and then delete the first. The items would then be something along the lines of:
deleted
done
done
not done
not done
We could keep it like this and keep track of the latest ID and just keep adding to it. The problem here is that after some heavy usage, you will only have tasks with IDs in the thousands or even ten thousands, making for clunky usage: todo 5242 done doesn't feel quite as nice as todo 4 done.
The alternative is that once a task is deleted, its ID is freed up. But what happens then? Do we keep track of "free" ids, which if we assume the above scenario, I create a new task and it will get ID 1.
Or do we say that there is no such thing as IDs - items are ordered by priority/due date (once we add those, before then I guess we use creation date) and any operation that takes an ID simply refers to that order - meaning if you add a task with high priority and you only have tasks with normal prio, the new task would get ID 1 and the rest would be 2, 3 4... and so forth.
The scenarios came up with above are the ones I feel all make sense in some way. In discussions, lets refer to them as ...
permanent IDs: IDs never free up.
recycled IDs: a deleted task's id is freed up and will be reused.
relative IDs: all IDs are relative to the current priority ordering.
If you can come up with another way of handling IDs, describe it and give it a name.
The text was updated successfully, but these errors were encountered:
Relative IDs make more sense, but we will then have to change the ordering of every element upon inserting or deleting a task.
Is there any way we could use relative ordering(user side) without having to update every task?
Relative IDs make more sense, but we will then have to change the ordering of every element upon inserting or deleting a task.
Is there any way we could use relative ordering(user side) without having to update every task?
Not a problem. If we use relative IDs, the actual database ID of the items wouldn't change or be used, and we would have some form of priority queue system to decide what an input ID actually means.
Should IDs be permanent? If not, when does an ID free up?
Imagine you create 5 tasks and mark the first 3 as done and then delete the first. The items would then be something along the lines of:
We could keep it like this and keep track of the latest ID and just keep adding to it. The problem here is that after some heavy usage, you will only have tasks with IDs in the thousands or even ten thousands, making for clunky usage:
todo 5242 done
doesn't feel quite as nice astodo 4 done
.The alternative is that once a task is deleted, its ID is freed up. But what happens then? Do we keep track of "free" ids, which if we assume the above scenario, I create a new task and it will get ID 1.
Or do we say that there is no such thing as IDs - items are ordered by priority/due date (once we add those, before then I guess we use creation date) and any operation that takes an ID simply refers to that order - meaning if you add a task with high priority and you only have tasks with normal prio, the new task would get ID 1 and the rest would be 2, 3 4... and so forth.
The scenarios came up with above are the ones I feel all make sense in some way. In discussions, lets refer to them as ...
If you can come up with another way of handling IDs, describe it and give it a name.
The text was updated successfully, but these errors were encountered: