Re: [incquery-dev] eclipsecon example

[Ábel Hegedüs <abel.hegedus@xxxxxxxxxx>]

Hi,

as I already stated, I feel that changing to the pattern registry may be too late for the EclipseCon demo. But I wanted to point out, that we will have to revisit the changes made to QSR and the setup of the dynamic scenario after the demo.

I know that we are short on time, but hacking the QuerySpecificationRegistry to register and unregister specifications is extremely bad practice,

So what would be a better policy? Hack the SettingDelegateFactory instead?

My main problem is that the QSR was meant to handle access to generated query specifications by FQNs. The register method is included to allow it to function without OSGi (users could register generated query specifications at startup).

A better policy would be to use the pattern registry (PR), in the way it was originally designed to work (afaik). That way, the QBF SetDelFact could pull the QuerySpec from the pattern registry, without knowing how it got there, while the pattern registry can handle the mixing of generated and generic queries, overwriting and removing query specs and the rest.

 

while we have the pattern registry functionality specifically designed for this use case (although it is not finished, unfortunately). When I initially created the delegate-based solution, I wanted to use the pattern registry, but then didn't as it introduced a new dependency. It would have been nice if that feature also got some progress as part of this demo.

What are currently the pros and cons of using the Pattern Registry? I have no objections against doing this properly, but I'd like to see more clearly in this matter.

Cons:

- added dependency, which would pull pattern registry into the main EIQ update site.

- unfinished code, afaik, there is only a first version, with much of the functionality not implemented or properly tested

Pros:

- cleaner handling of (re/un)registering queries and FQN clashes

- transparent access to generated/generic queries (QSR is hidden behind PR)

- kick-off the migration for the rest of the framework and test drive the implementation

- avoiding polluting QSR with additional responsibilities

Once again, for the sake of the demo, I accept the "it works, now don't touch anything" mentality and would advise against changing to PR, if the current setup works.

   Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics