Currently we have keys/2 and match/4. We could also make a keys/1 that returns all keys, and a match/3 that omits the `key` argument (trickier because there is already a /3 variant with the 4th optional argument).
What do you think? (I have also noticed from making Horde that a lot of people want this functionality, which I had added, but later deprecated since I was aiming for API parity with Elixir's Registry. It would be nice to have this functionality added back again so that there is one way to get this done.) On Wed, Apr 17, 2019, at 09:56, José Valim wrote: > I agree. Let's go ahead with what you have originally proposed. In case of > multiple partitions, we will simply concatenate the results. We will add a > note that it is potentially expensive on duplicate registries with multiple > partitions. We can add a stream_all/1 in the future if necessary. > > My only last question is about the function name. Registry.all/1 makes sense > but if we want to add a version that also supports match specs, then we would > need to add Registry.all_match/3, if we are to keep the current convention. > But I think "all_match/3" is a bit awkward? Any further thoughts on the name? > > Note Registry.match/4 already exists and it performs a match under a given > key. > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On Wed, Apr 17, 2019 at 9:44 AM <[email protected]> wrote: >> I understand the value of implementing it the way `Registry.dispatch` works, >> but it makes using it a bit awkward. In the example use case I gave earlier, >> it would look something like this in the coordinating process >> >> ``` >> handle_info(:interval, state) do >> new_keys = get_keys_from_external() >> Registry.all(registry, fn entries -> >> current_keys = Enum.map(entries, &(elem(&1, 0)) >> synchronize(current_keys, new_keys) >> end) >> end >> ``` >> >> Which is okay, I guess, but the data is stuck in the callback. Also, if we >> copy the way that dispatch handles partitions the code would only work if >> there aren't multiple partitions. Not sure how I'd go about collecting the >> entries from multiple partitions, maybe in an ETS table? Sending to myself >> and storing in state? Either way, it's not very ergonomic. Maybe I'm missing >> an obvious solution. >> >> Would it make sense to implement it as a Stream? It should provide some of >> the same properties as the dispatch solution. We could iterate over the >> tables and handle partitions seamlessly. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:elixir-lang-core%[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/503ef13f-9e18-4e64-8e1c-84ca677ab504%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JO%3DjveXLf5RHyGqsnNVnjpLW1%2BsDV%2BHpRv8LD9ZwWkkw%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JO%3DjveXLf5RHyGqsnNVnjpLW1%2BsDV%2BHpRv8LD9ZwWkkw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/bb836f3f-9320-424b-978c-3ae580810e18%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
