What about use D) and also give a way to user specify the default classes to all queries?<br><br><div class="gmail_quote">On Wed, Apr 27, 2011 at 5:10 AM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On 27 avr. 2011, at 08:57, Sanne Grinovero wrote:<br>
<br>
> 2011/4/27 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
>> Users can put indexed or nit indexed superclasses in the query target type. That would not work for you as you can't discover known subtypes wo scanning or having a closure of types somewhere.<br>
><br>
> sure they can with Hibernate Search. but should they be able with<br>
> Infinispan Query?<br>
> If the answer is yes, then we still need to find an alternative.<br>
<br>
</div>Well it's an OO query and thus subtype polymorphism should apply.<br>
<div><div></div><div class="h5"><br>
><br>
><br>
>> On 26 avr. 2011, at 23:32, Sanne Grinovero <<a href="mailto:sanne.grinovero@gmail.com">sanne.grinovero@gmail.com</a>> wrote:<br>
>><br>
>>> Hello,<br>
>>> I'm forking off this thread, as we never resolved how to cope with the<br>
>>> main issue:<br>
>>><br>
>>> how is Infinispan Query going to be aware of which entities are to be<br>
>>> considered as default targets for a Query?<br>
>>><br>
>>> the realistic ideas so far:<br>
>>> A) class scanning: seems nobody liked this idea, but I'll still<br>
>>> mention it as the other options aren't looking great either.<br>
>>> B) scan known indexes (need to define what the "known indexes" are as<br>
>>> we usually infer that from the classes)<br>
>>> -- could enforce a single index<br>
>>> C) have to list all fully qualified class names in the configuration<br>
>>> D) don't care: consider it a good practice to specify all targeted<br>
>>> types when performing a Query.<br>
>>> E) please suggest :)<br>
>>><br>
>>> The currently implemented solution is D, as it requires no coding at all :)<br>
>>> considering the simplicity of it I'm liking it more the more I think<br>
>>> about it; I could even polish the approach by adding a single line to<br>
>>> log a warning when the user doesn't respect the best practice, or to<br>
>>> mandate it.<br>
>>><br>
>>> Considering that when a Query is invoked specifying the target types<br>
>>> there is no doubt we know the classes, I could add a warning in case<br>
>>> the Query is performed without specifying the type: in that case it<br>
>>> usually implies the query targets all known types, which is always<br>
>>> fine when using Hibernate Search, but could be inconsistent with<br>
>>> Infinispan Query as it might not have discovered all types yet (1), so<br>
>>> a very simple solution is to mandate the type parameter.<br>
>>><br>
>>> [1] - when the Cache interceptor hits an event adding a new type, the<br>
>>> Search engine is reconfigured.<br>
>>><br>
>>> thoughts?<br>
>>><br>
>>> Sanne<br>
>>><br>
>>><br>
>>> 2011/4/5 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
>>>><br>
>>>> On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:<br>
>>>><br>
>>>>> 2011/4/5 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
>>>>>><br>
>>>>>> On 5 avr. 2011, at 12:20, Galder Zamarreño wrote:<br>
>>>>>><br>
>>>>>>><br>
>>>>>>> On Apr 4, 2011, at 6:23 PM, Sanne Grinovero wrote:<br>
>>>>>>><br>
>>>>>>>> </snip><br>
>>>>>>>><br>
>>>>>>>> there's one catch:<br>
>>>>>>>> when searching for a class type, it will only include results from<br>
>>>>>>>> known subtypes. The targeted type is automatically added to the known<br>
>>>>>>>> classes, but eventually existing subtypes are not discovered.<br>
>>>>>>>><br>
>>>>>>>> Bringing this issue to an extreme, if the query is not targeting any<br>
>>>>>>>> type, and no indexed types where added to the grid (even if some exist<br>
>>>>>>>> already as they might have been inserted by other JVMs or previous<br>
>>>>>>>> runs), all queries will return no results.<br>
>>>>>>>> How to solve this?<br>
>>>>>>>> - class scanning?<br>
>>>>>>><br>
>>>>>>> Nope, too expensive.<br>
>>>>>>><br>
>>>>>>>> - explicitly list indexed entities in Infinispan configuration?<br>
>>>>>>><br>
>>>>>>> No<br>
>>>>>>><br>
>>>>>>>> - a metadata cache maintaining a distributed&stored copy of known types<br>
>>>>>>><br>
>>>>>>> That sounds more appealing. It could be a good middle ground until Search can search for types.<br>
>>>>>><br>
>>>>>> Do you have any specific idea in mind?<br>
>>>>>><br>
>>>>>> To magically find types:<br>
>>>>>> - we scan every file system, databases, caches available to the app and look for Lucene metadata => unrealistic<br>
>>>>>> - there is some kind of convention on where the indexes are and we do index scanning at startup => scanning are very likely to be slower that class scanning (potential remote access, bigger dataset etc)<br>
>>>>>> - we enforce one or a fixed number of Lucene indexes for all data in Infinispan => not sure that's a good idea but this can be explored<br>
>>>>>> - we somehow ask the framework using HSearch to fill up classes<br>
>>>>>><br>
>>>>>> other approaches?<br>
>>>>><br>
>>>>> why was class scanning discarded in the first answer? as H. Search can<br>
>>>>> auto-discover classes by working on top of JPA entity autodiscovery, I<br>
>>>>> guess that each application node could look into it's own known<br>
>>>>> classpath.<br>
>>>>> After all if some type is not visible to him as it was added from<br>
>>>>> another node from a different app, he won't be able to return<br>
>>>>> instances of it either.<br>
>>>>> We could face the opposite problem of building metadata of classes<br>
>>>>> people doesn't mean to index in this cache.<br>
>>>><br>
>>>> Right. scanning (class or index) will be a bit aggressive and could build unneeded metadata (or even worse, return unexpected classes).<br>
>><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br>