-
Notifications
You must be signed in to change notification settings - Fork 393
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
Question: any reason to check that new entry timestamp is newer than previous? #257
Comments
Because the FlashDB uses the binary search algorithm to search TSDB. The search will cause problems when timestamp cannot keep incrementing. |
If the binary search is used just for iteration functions then what about make this feature less restrictive? I see few options:
|
If you know it's wrong, why do you do it? |
Well, this will work if it's necessary just to display last 100 saved records. Also this will prevent situations like I described in my first message - when the date was changed to the future and then changed back. Because there is no functionality to delete specific TSDB record it can lead to a deadlock - you will not be able to save anything until you either clean whole partition or wait until your actual date will be greater than last saved. |
Hi.
I'm referring to this line https://github.com/armink/FlashDB/blob/a208b1555b9805c4fb13336b0c1529d2df8d5641/src/fdb_tsdb.c#L398C6-L398C6
Any reason to perform this check? What bad can happen if user will be allowed to save TSDB entries with "out-of-order" timestamp?
I'm just thinking about situation when having this check can break TSDB data appending. Example:
UPD:
I'm actually faced such situations while developing firmware, but in my case (time_t is int64) I got a saved event somewhere in the year 32012 :-)
The text was updated successfully, but these errors were encountered: