I already explained this ... just 30 months ago ;-) http://lists.jboss.org/pipermail/infinispan-dev/2011-April/008000.html
Sanne On 20 September 2013 17:31, Mircea Markus <[email protected]> wrote: > > On Sep 20, 2013, at 4:44 PM, Adrian Nistor <[email protected]> wrote: > >> Could you detail please? > > +1 :-) > >> >> On 09/20/2013 05:43 PM, Sanne Grinovero wrote: >>> On 20 September 2013 11:19, Mircea Markus <[email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> Cheers, >>>> -- >>>> Mircea Markus >>>> Infinispan lead (www.infinispan.org) >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
