Thanks for the heads up!
It's not clear for me what the functional impact of ISPN-2143 is: incomplete query
results?
On Sep 19, 2013, at 11:42 AM, Sanne Grinovero <sanne(a)infinispan.org> 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)