Indexing Items by Last Updated Time in Deno KV
Hello, I need some help with indexing in Deno KV. I have a list of threads, and each thread contains posts. When a post is added to a thread, I want to update the "last updated" timestamp for that thread. Additionally, I need to sort the threads by their "last updated" timestamp.
I created a secondary index with the key space
['last_updated', lastUpdatedTime, threadId]
. However, this approach results in duplicates because I can't remove the older "last updated" timestamps. My goal is to get a list of 200 unique threads, sorted by the "last updated" timestamp.
How can I achieve this without getting duplicate entries for the same thread? Is there a way I can do this with secondary indexes?10 Replies
I apologize, but I wasn't able to find the answer to your question in the official Deno documentation. However, based on the information you've provided, it seems like you're trying to maintain a unique index for each thread based on the "last updated" timestamp.
One potential issue with your current approach is that you're creating a new index entry every time a thread is updated without removing the old entry, which leads to duplicates. To avoid this, you would typically need to ensure that you update the existing index entry for a thread rather than creating a new one each time.
Since I don't have access to the specifics of how Deno KV handles secondary indexes, I can't provide a Deno-specific solution. However, a common approach in such scenarios is to:
1. Retrieve the current index entry for the thread if it exists.
2. Update the index entry with the new "last updated" timestamp.
3. Save the updated index entry back to the KV store.
This advice is not based on the Deno documentation, so please double-check the accuracy of this advice and consider reaching out to the Deno community or reviewing the Deno KV documentation for more specific guidance on handling secondary indexes and unique constraints within Deno KV.
I see the issue. One way to go about it might be to delete the existing index entries and then setting the new one on every update, so that there is always only 1 copy of any given thread:
This might be a bit excessive, but I dont really see any way to use unique indexing when there is a timestamp and id involved.
This actually makes a lot of sense, I never would have thought of that. Thank you!
Just a heads up, the id and lastUpdated parts of the secondary index key should maybe be flipped?
Why so? Wouldn't I query by
Which would return a list of threads sorted by last updated, with a limit of 20.
yeah, actually that part makes sense. But when deleting them, I think there will be an issue since it might delete other thread entries with the same lastUpdated value?
I dont think my proposal is a valid solution after all
I think this would work
yeah
And when a thread is updated I could do something like this
It's a little exhaustive, but that's just the nature of working with the kv
Since you knwo it will be only 1 entry I think that should be fine