Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Task IDs #10

Open
pobiega opened this issue May 6, 2021 · 2 comments
Open

Discussion: Task IDs #10

pobiega opened this issue May 6, 2021 · 2 comments

Comments

@pobiega
Copy link
Collaborator

pobiega commented May 6, 2021

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:

  1. deleted
  2. done
  3. done
  4. not done
  5. 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.

@18-F-cali
Copy link
Contributor

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?

@pobiega
Copy link
Collaborator Author

pobiega commented May 7, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants