GitHub user torwig added a comment to the discussion: Talks about the design of consumer group in stream
Since the entry ID is a subkey for a full stream record key (stream_name + entry_id) and if we disallow starting a consumer group's name and a consumer's name with a number then maybe it will allow us to distinguish a key of a regular stream element from other keys related to CG implementation. I think that all the keys related to a CG should start with a stream name because, in the case of a stream deletion, we need to delete all his CGs with their consumers and PEL. Generally, I think that the provided approach may work if each case is clearly distinct from others. 1. Stream_Name + CG_Name + Some_Way_Of_Metadata_Definition -> CG's Metadata. 2. Stream_Name + CG_Name + Consumer_Name [ + Some_Way_Of-Metadata_Definition ] -> Consumer's Metadata (more than just last_seen timestamp, see `XINFO CONSUMERS`). 3. PEL entries: Stream_Name + CG_Name + Stream_Entry_ID -> (owner, delivery time, delivery count). Perhaps, we need to implement it differently to efficiently change the owner of delivered entries with the `XCLAIM` command (we need to answer the query "Give me elements from PEL, delivered to consumer X which satisfy some conditions related to idle time and delivery count ). GitHub link: https://github.com/apache/kvrocks/discussions/1654#discussioncomment-6802708 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
