[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [incquery-dev] Hybrid pattern matching, IQueryResultProvider interface
|
Hi,
Thanks for your suggestions!
hasMatch()
OK, we can add this one easily; I can see how it would help.
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?
It should return null if there are no matches, just like you said. The
Javadoc obviously needs some more love here.
So you are right, getOneArbitraryMatch() can be a substitute for hasMatch().
But I am not strongly against adding the latter to the interface, should you
prefer it.
Márton, can you elaborate further your complaint on initialization and type
safety?
Initialization should happen when IQueryBackend#getResultProvider(PQuery) is
invoked. What concern of type safety do you see there?
Though this has nothing to do with the initialization of the result
provider, when the matches are later returned by the result provider, they
consist of Objects, since IQueryResultProvider is an uniform interface for
all queries.
Cheers,
Gábor
-----Original Message-----
From: Ujhelyi Zoltán
Sent: Thursday, April 30, 2015 10:44 PM
To: Incquery developer discussions
Subject: 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
_______________________________________________
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