Now I'm a little confused about why we can't use the classes colected on QueryInterceptor...<br><br>> Infinispan Query as it might not have discovered all types yet (1)<br><br>Probably I am missing some point, but to me it is not a problem. <br>
<br><div class="gmail_quote">On Fri, Apr 29, 2011 at 3:36 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne.grinovero@gmail.com">sanne.grinovero@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/4/29 Israel Lacerra <<a href="mailto:israeldl@gmail.com">israeldl@gmail.com</a>>:<br>
<div class="im">> What about use D) and also give a way to user specify the default classes to<br>
> all queries?<br>
<br>
</div>Yes that's the idea; but we need to figure out how the user specifies<br>
the default classes; so far nobody liked any proposal.<br>
<font color="#888888"><br>
Sanne<br>
</font><div><div></div><div class="h5"><br>
><br>
> On Wed, Apr 27, 2011 at 5:10 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
> wrote:<br>
>><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<br>
>> >> type. That would not work for you as you can't discover known subtypes wo<br>
>> >> 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>
>> Well it's an OO query and thus subtype polymorphism should apply.<br>
>><br>
>> ><br>
>> ><br>
>> >> On 26 avr. 2011, at 23:32, Sanne Grinovero <<a href="mailto:sanne.grinovero@gmail.com">sanne.grinovero@gmail.com</a>><br>
>> >> 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<br>
>> >>> 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<br>
>> >>>>>>>> from<br>
>> >>>>>>>> known subtypes. The targeted type is automatically added to the<br>
>> >>>>>>>> known<br>
>> >>>>>>>> classes, but eventually existing subtypes are not discovered.<br>
>> >>>>>>>><br>
>> >>>>>>>> Bringing this issue to an extreme, if the query is not targeting<br>
>> >>>>>>>> any<br>
>> >>>>>>>> type, and no indexed types where added to the grid (even if some<br>
>> >>>>>>>> exist<br>
>> >>>>>>>> already as they might have been inserted by other JVMs or<br>
>> >>>>>>>> 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<br>
>> >>>>>>>> types<br>
>> >>>>>>><br>
>> >>>>>>> That sounds more appealing. It could be a good middle ground until<br>
>> >>>>>>> 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<br>
>> >>>>>> app and look for Lucene metadata => unrealistic<br>
>> >>>>>> - there is some kind of convention on where the indexes are and we<br>
>> >>>>>> do index scanning at startup => scanning are very likely to be slower that<br>
>> >>>>>> class scanning (potential remote access, bigger dataset etc)<br>
>> >>>>>> - we enforce one or a fixed number of Lucene indexes for all data<br>
>> >>>>>> 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<br>
>> >>>>> can<br>
>> >>>>> auto-discover classes by working on top of JPA entity autodiscovery,<br>
>> >>>>> 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<br>
>> >>>> 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>
><br>
><br>
</div></div></blockquote></div><br>