[infinispan-dev] Query and dynamic discovery of types

[Adrian Nistor]

Could you detail please?

On 09/20/2013 05:43 PM, Sanne Grinovero wrote:
> On 20 September 2013 11:19, Mircea Markus <mmarkus at redhat.com> 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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev