ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Replacing NodeFilter functionality with label approach
Date Mon, 05 Aug 2019 13:28:30 GMT
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 <nizhikov@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,
> 
> 
> 

Mime
View raw message