Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IbeXContextAlternatives are handled incorrectly for unidirection match subscriptions #87

Open
FabianMarcoBauer opened this issue Apr 14, 2019 · 2 comments
Assignees

Comments

@FabianMarcoBauer
Copy link
Contributor

When enriching unidirectional rules with a disjunction of conditions, ibex creates an IBexContextAlternative-entry in the IBeXPatternSet. In the IBexContextAlternative, the alternatives are contained as IBeXContextPatterns with different names. Each of the alternative patterns is then transformed to an individual democles pattern with the names from the ibex patterns.
When the application now tries to subscribe to appearing or disappearing matches for the pattern, the original pattern name is used for the subscription. ibex-democles on the other hand uses the name of the alternative patterns to publish changes. This means that the subscribing application is never informed about the change.

By manually registering listeners on each of the alternative pattern names (for example by setting the patternName-field in the MyPatternPattern via reflection), the updates can still be received. But this requires the application to manually subscribe to all variations and filter for duplicates when the conditions are not mutually exclusive.

Example:
Pattern

pattern myPattern() {
...
} when conditionA or conditionB

conditionA = ...
conditionB = ...

ibex-patterns.xml:

IBe XContext Alternatives myPattern
┣ IBe XContext Pattern myPattern-ALTERNATIVE-conditionA
┗ IBe XContext Pattern myPattern-ALTERNATIVE-conditionB

democles-patterns.xmi:

Pattern myPattern-ALTERNATIVE-conditionA
Pattern myPattern-ALTERNATIVE-conditionB

Registration:

// ...
api.myPattern().subscribeAppearing(System.out::println); // never receives matches

Field declaredField = MyPatternPattern.class.getDeclaredField("patternName");
declaredField.setAccessible(true);
declaredField.set(MyPatternPattern.class, "myPattern-ALTERNATIVE-conditionA");
api.myPattern().subscribeAppearing(System.out::println); // now receives matches for conditionA
// ...
@anthonyanjorin
Copy link
Contributor

Hi Fabian,

What exactly are you working on? Would you like to fix this bug yourself? Lars and I would be happy to provide assistance, and we have regression tests.

I personally won’t be able to investigate and fix this in the next 3-4 weeks due to upcoming conference deadlines and teaching.

Cheers,
Tony

@FabianMarcoBauer
Copy link
Contributor Author

Hello Tony,

I tried to fix the bug myself and I managed to notify the correct subscribers, but I was unable to prevent duplicates if multiple alternatives matched the same objects.

In the meantime I will work around this issue by creating an individual pattern for each condition and filtering for duplicates on my end.

Best regards
Fabian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants