[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [incquery-dev] Hybrid pattern matching, IQueryResultProvider interface
|
Hi,
about the missing hasMatch(), that is a fair point. It is very important for non-indexing matchers, as accessing the first result is _much_ cheaper than accessing all results. It is possible that the getOneArbitraryMatch is a good candidate for this reason; however, the Javadoc does not describe the expected result if no match is available (although I guess it is null). Gábor, can you remember the intended meaning for this case?
About initialization, I don't see where additional type information is needed: as far as I know, you only have to provide Tuples/Object[] instances. Could you share some code that illustrates the problematic case?
Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
On 2015.04.30., at 21:50, Márton Búr wrote:
> Hi,
>
> I found that method hasMatch() is missing. In addition, for initialization
> of the wrapped matchers type info might also be helpful, so that typecast
> can be done in a safe way when needed, but without using instanceof.
>
> Cheers,
> Marci
>
> On Wed, Apr 29, 2015 at 7:55 PM, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:
>
>> Hi,
>>
>> Just a stupid question, as it is not clear to me: exactly what methods
>> would be needed on IQueryResultProvider?
>>
>> Cheers,
>> Zoli
>> -- Zoltán Ujhelyi
>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>>
>> On 2015.04.29., at 16:56, Márton Búr wrote:
>>
>>> Hi Everyone,
>>>
>>> Recently I have started working on the hybrid pattern matching and I'm
>>> stuck at a point. From the viewpoint of local search I saw two possible
>>> ways of continuing development:
>>> - in the IMatcherBasedOperations (e.g. BinaryTransitiveClosureCheck), in
>>> which currently a LocalSearchMatcher is stored, use the
>>> IQueryResultProvider interface. To be able to do so, some methods should
>> be
>>> added to the interface, for the IMatcherBasedOperation implementations
>>> inside use some methods of the LocalSearchMatcher that are not part of
>> the
>>> IQueryResultProvider interface.
>>> This way it would be OK to provide runtime the IQueryResultProvider from
>>> the context, as it is done now for the LocalSearchMatcher, and it is not
>>> necessary to know the matcher algorithm at plan compilation time.
>>> - create matcher based operations that are capable of storing and calling
>>> RetePatternMatcher (subclass of IQueryResultProvider) in addition to the
>>> existing IMatcherBasedOperations. This case the POperationCompiler should
>>> know which operation to insert during the compilation of the plan: the
>>> local search or the incremental matcher based. This information will
>>> probably not be available when the plan is made. However, if we only do
>>> planning runtime, and already know the existing rete matchers and model,
>>> this could be an option.
>>>
>>> I hope it is more or less clean what I wanted to ask, please reply if
>> not.
>>>
>>> Thanks in advance for the advices,
>>> Marci
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/incquery-dev
