Ivan, ~Mail~ Talks are cheap! Show me the code (C) :)
class NodeAttributeFilter<T> implements IgnitePredicate<ClusterNode> {
private String name;
private T value;
public boolean apply(ClusterNode n) {
return Objects.equals(n.attribute(name), value);
}
//...setters, getters.
}
В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> Hi Nikolay,
>
> Could you please elaborate how will NodeAttributeFilter behave? Do you
> mean specifying attribute name and value for exact comparison inside?
> Without any dynamic (user) code involved?
>
> Also I it is quite interesting for me what flexibility you are
> thinking about? I think that the topic is quite important and it would
> be great to collect use cases and describe best practices in
> documentation.
>
> пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov <nizhi...@apache.org>:
> >
> > Hello, Pavel.
> >
> > I think we shouldn't reduce flexibility of NodeFilter.
> > So, I am -1 to remove it in Ignite 3.
> >
> > Instead, Ignite can provide NodeAttributeFilter implementation of
> > NodeFilter.
> > Seems, it will resolve all described issues.
> >
> >
> > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > Hello!
> > >
> > > I think this is a good idea. We already had problems with ClusterGroups
> > > that won't recompute until PME, or which become invalid after PME. Relying
> > > on string labels would fix all that.
> > >
> > > I can think of a node filter which can't be replaced with label filter
> > > (e.g. the one checking for presence of some partition) but generally
> > > that's
> > > a Bad Idea.
> > >
> > > Regards,
>
>
>
signature.asc
Description: This is a digitally signed message part
