[infinispan-dev] Query and dynamic discovery of types

[Sanne Grinovero]

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 <mmarkus at redhat.com> wrote:
>
> On Sep 20, 2013, at 4:44 PM, Adrian Nistor <anistor at redhat.com> 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 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
>>
>> _______________________________________________
>> 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)
>
>
>
>