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

Generated IDs are not unique when multiple per minute are created #71

Closed
EFLS opened this issue Jul 1, 2020 · 4 comments · May be fixed by #125
Closed

Generated IDs are not unique when multiple per minute are created #71

EFLS opened this issue Jul 1, 2020 · 4 comments · May be fixed by #125
Labels
bug Something isn't working

Comments

@EFLS
Copy link
Owner

EFLS commented Jul 1, 2020

By default, IDs are based on time up to the minute. Because of this, IDs are not unique when two are created within the same minute. This is mentioned in the literate code, but should ideally be prevented.

@EFLS EFLS added the bug Something isn't working label Jul 1, 2020
@TRSx80
Copy link

TRSx80 commented Aug 25, 2020

I am willing to start contribootin'. 😄

Perhaps next step is to start throwing implementation ideas around?

One such idea would be to create a new internal variable, something like zetteldeft--last-timestamp and use it to store the last generated timestamp. Then a simple check in the creation function (or wherever appropriate) to make sure current time != zetteldeftr-last-timestamp and if it is simply give an error message so the user knows what happened.

In practice, I think it pretty rare that 2 notes get generated within same second, but it probably is an edge case that would be nice to address.

We could at the same time check for duplicate already existing IDs (although maybe there is already a check for that; I am still getting familiar in-depth with the code base) as I suppose there could be some edge case where you are traveling and crossing time zones, etc... Another rare case, but possible...

@EFLS
Copy link
Owner Author

EFLS commented Aug 25, 2020

Well, the default timestamps / IDs are only down to the minute, not even the second, so this is an important issue indeed.

Moreover, as of a couple of months ago, zetteldeft-custom-id-function can be used to to generate IDs in custom fashion. Ideally, a general check for duplicate IDs should take this into account.

The general check is the better option, I think, and should be easy enough to implement: simply check whether a filename with such a freshly generated string already exists and throw a warning if it does. There is currently no general function that identifies out duplicate IDs.

@TRSx80
Copy link

TRSx80 commented Aug 25, 2020

Well, the default timestamps / IDs are only down to the minute, not even the second, so this is an important issue indeed.

Derp! Of course you are right.

Now realizing we are talking about minutes, and not seconds, which of the following should our implementation do?

  1. Simply give error message in minibuffer, and not allow user to do anything until one minute has passed.
    • On one hand, this is probably the simplest implementation.
    • OTOH, I really don't like my computer being obstinate with me. I am the one who is in charge here. lol So...
  2. Automatically advance the timestamp to the next minute (perhaps with a message to the user)?
    • Could get complex if they are doing some rapid fire note adding. Although properly coded would be something like a recursive forward checking algorithm in case eg. +3 notes have already been added...
  3. Make this behavior configurable?
  4. Extend the resolution to seconds (add 2 digits)?
    • I don't like this. I rather prefer the nice, shorter ID, given how frequently the IDs show up everywhere.

On balance, I think I prefer option 1, at least for a first pass (and maybe even forever).

I can't help but wonder how often this really actually happens (so if you are reading this, please add your $0.02!). Speaking only for myself, I know I am editing a new note for at least one minute, and often more. I think that if you are doing Zettelkasten correctly that you are similarly putting some thought into it (editing, writing, etc.). However I also realize that some times you are just "capturing" things to come back to later (and then perhaps, even rapid-fire...). So, yeah...

So I suppose that determining how frequently this happens will help us really strike the right balance between eg. option 1 and option 4, above.

Moreover, as of a couple of months ago, zetteldeft-custom-id-function can be used to to generate IDs in custom fashion. Ideally, a general check for duplicate IDs should take this into account.

Yes, I think the correct place would be to put it right before any sort of ID were generated, whether custom or not.

The general check is the better option, I think, and should be easy enough to implement: simply check whether a filename with such a freshly generated string already exists and throw a warning if it does. There is currently no general function that identifies out duplicate IDs.

OK, cool. Thanks for the insight. I think we have at least that part of it nailed down. the "general check" function could actually return "first available time stamp" in the event we decide to go with option 2, above.

In fact, suddenly option 2 is sounding more elegant, and not terribly difficult to implement, I don't think, especially given the fact that "There is currently no general function that identifies out duplicate IDs."

But now I am thinking more about implications of zetteldeft-custom-id-function. I just took a look briefly at that. Maybe require it to also accept "next available time stamp" in addition to 'TITLE'?

But my head starting to hurt now. And I think we should decide first on implementation behavior. So I will revisit later.

@EFLS
Copy link
Owner Author

EFLS commented Sep 20, 2020

I've updated the function that generates IDs to include a rudimentary check to ensure that the IDs are indeed unique: a3333b7. It throws an error when the ID is not unique (wether it is generated by zetteldeft-custom-id-function, or simply a time-based ID).

It's just a general check, nothing fancy, but should be sufficient for now. I'm happy to include more refined code if people submit it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants