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]. > 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. For more options, visit https://groups.google.com/d/optout.
