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

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

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)