Re: [infinispan-dev] Query and dynamic discovery of types

On Sep 20, 2013, at 4:44 PM, Adrian Nistor <anistor(a)redhat.com&gt; wrote: > Could you detail please? +1 :-) > > On 09/20/2013 05:43 PM, Sanne Grinovero wrote: >> On 20 September 2013 11:19, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >>> Thanks for the heads up! >>> >>> It's not clear for me what the functional impact of ISPN-2143 is: incomplete query results? >> yes >> >>> On Sep 19, 2013, at 11:42 AM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >>> >>>> For Infinispan 6.0 we decided that the following issue is a bloker: >>>> >>>> https://issues.jboss.org/browse/ISPN-2143 - Improve how different >>>> indexed caches sync up on new indexed types >>>> >>>> It really is important, and I'm a bit concerned that it was moved to >>>> CR1 as it might not be trivial: for embedded query it needs to store a >>>> reference to class definitions (potentially with classloader >>>> information too), and for remote queries it needs to distribute the >>>> indexing configuration schema. >>>> >>>> Also I'm wondering if we shouldn't go even further: in Hibernate >>>> Search the internal complexity of handling newly appearing types >>>> (rather than statically configured types) is very hard. >>>> >>>> In the next version we might need to drop this, so it would be great >>>> if we could stabilize the Infinispan Query API right now in such a way >>>> that it won't need this feature anymore. >>>> >>>> I proposed it years ago but it was rejected because of usability >>>> concerns.. would you still reject the idea to simply list the indexed >>>> types at configuration time? If so, I think we need to explore >>>> alternative solutions. >>>> >>>> Note that I only want to remove the dependency to dynamic _Class_ >>>> definitions being added at runtime; we will still support dynamically >>>> defined types so in case you need extreme flexibility like with remote >>>> queries that will work, as long as you provide a smart bridge able to >>>> reconfigure itself based on the dynamic metadata; I think that's a >>>> cleaner approach as you would be directly in control of it rather than >>>> having to workaround a design which was thought for a different >>>> purpose. >>>> >>>> Sanne >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> Cheers, >>> -- >>> Mircea Markus >>> Infinispan lead (www.infinispan.org) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)