Re: [incquery-dev] Hybrid pattern matching, IQueryResultProvider interfa

[Bergmann Gábor <bergmann@xxxxxxxxxx>]

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