Object Update Trigger by milt · Pull Request #40 · yetanalytics/federate-xapi

milt · 2026-07-27T15:40:13Z

Trigger statement emission from object updates

Make Object Cache reflection writes atomic
Introduce three new trigger types: ObjectCreate, ObjectUpdate and ObjectDelete
- ObjectCreate is fired at most once when an object is created, upon the first reflection of requested attributes
- ObjectUpdate is fired on every update (including the first reflection).
  - The previous expression is now available in ObjectUpdate to refer to the previous state of the object. This can be used to implement change detection.
- ObjectDelete is fired at most once when an object is deleted.
  - The trigger expression in ObjectDelete can access a snapshot of the object's attributes prior to deletion.
Overhaul object subscription to merge requested class attributes via their hierarchy
prevent cache misses across class hierarchies in queries

…work Concrete Classes and Descendent Subs

cliffcaseyyet

Very cool, I understand this iteration better than the ones before it. Most of my stuff is organizational or minor but what it's actually doing makes sense.

cliffcaseyyet · 2026-07-29T17:43:59Z

- `type`: Type of trigger. `Interaction` is currently wired into RTI subscriptions and statement processing. `ObjectUpdate` is parsed by the config model but object updates currently feed the object cache rather than firing statement triggers directly.
- `class`: The local HLA interaction class name. For interactions this is matched against the final segment of the RTI interaction class name.
+- `type`: One of `Interaction`, `ObjectCreate`, `ObjectUpdate`, or `ObjectDelete`.
+- `class`: Local HLA interaction or object class name. Matching is exact: an object trigger for `SimEntity` does not also fire for a reflection reported as `Rabbit`.


you removed the text about the final segment of the interaction classname. Did that change or get moved somewhere else?

I think that was just accidentally removed from the docs and is still the case, but we might actually want to use the same convention as Object classes, ie we don't require root but fully qualify below that? dunno

A conflict is possible in a complex fom with multiple intermediate interaction classes is my point

Ok, if we want to lean FQN then I'm fine with that. Does that mean most of the examples should be SimEntity.Rabbit or whatever?

cliffcaseyyet · 2026-07-29T19:57:42Z

+import org.springframework.stereotype.Component;
+
+@Component
+public class StatementTriggerDispatcher {


From prior conversation, I am still not convinced this needs to be a component or even a class, and can probably just go as functions right into the TriggerProcessor. This is pretty low priority on my list though.

I have no problem with that

cliffcaseyyet · 2026-07-31T20:02:10Z

    private List<Object> statementPath = List.of();
    private boolean embedded = false;
    private String objectType;
+    private StatementTrigger.Type triggerType;


eeeep this is problematic. We were using inheritance to determine between Interaction and Object when we only had two. This property provides the ability for it to get janky, i.e. an InteractionInjectionContext with a OBJECT_DELETE trigger type. It creates ambiguity as to what determines the type. Following the existing convention you should just make two more extensions from InjectionContext (or have three extend ObjectInjectionContext which you make abstract to get the attributes fields). Or at the very least this should be a field in ObjectInjectionContext only and have an enum with UPDATE, CREATE, DELETE only.

On the complete other end you could refactor to not use inheritance at all but then you would need to account for the differences in a single class AND you would lose the intentional overloads in injectionhandler and have to replace them with more logic.

cliffcaseyyet · 2026-07-31T20:14:19Z

-        if (injectionContext instanceof TestInjectionContext) {
-            return handler.handleLookup(null, target, injectionContext);
+        if (injectionContext instanceof TestInjectionContext testContext) {
+            return handler.handleLookup(alias, definitions.get(alias), target, testContext);


i'm having trouble figuring out what this is doing, perhaps i didn't understand what it was doing before either and why it needs to be different from the non-validation runs.

I did catch up to this in another comment but i'll leave it here until that one is figured out.

cliffcaseyyet · 2026-07-31T20:23:25Z

+                : interactionTargetDefinition(hlaClass, target);
+    }
+
+    private EventTargetDefinition requireEventTargetDefinition(


A good amount of this stuff seems like essentially syntax validation against the FOM, which I would have expected more at the parse stage than the execution stage? It seems to be doing deep FOM inspection of every layer of target validity in the middle of actual processing here. Was there a particular reason that it needed to be processing-time?

I believe this is called during validation by TriggerProcessor.renderTemplateForValidation() but not during a run, I think that is bypassed, but I can chase it down and get a more satisfying answer.

cliffcaseyyet · 2026-07-31T20:28:00Z

        return objectCache.findValueResolution(object, attrTarget);
    }

+    public ValueResolution handleLookup(


ah ok i think i get it now per my other question. It cannot pass a CachedObject as the others do beacuse it doesn't have one.

I think part of why this is weird is that it's chosen to already resolve the cachedobject outside the injection handler instead of having the injectionhandler do that work on receiving the details of an injection. Might be worth considering a refactor there, but perhaps there is another structural reason it needs to be done before the injection is being handled?

milt added 22 commits July 27, 2026 11:39

make reflection cache updates atomic

d6c04f1

add class, obj handle, attributes to ObjectInjectionContext

d151cf7

separate cache and event subscriptions

9642a50

shared trigger dispatcher

6d48e60

add working objectupdate to xapi config

13c7cbe

object snapshot holds attributes of deleted object

7f451b3

add new trigger types to model

047d5d8

config tests for new trigger types

99c043c

implement create and delete trigger types and handle short lifespan

e80af9d

properly search child classes

7e0fb7d

previous keyword is only available in ObjectUpdate

28dab8f

use previous in demo config

72319a6

increased validation to ensure previous only used in correct cases

de77cdf

don't emit statements for empty update callbacks

8f801a8

object subscription plan

ceae791

use object subscription plan and combine ancestor subscriptions

05e8c03

allow optional malformed arrays and fixedrecords to return null

de1e79f

docs

de642fd

redundant anno

1e19f9f

remove silly test

4ed623c

revert to original creds

98192e0

Merge branch 'main' into object_update_trigger

f1c3666

milt marked this pull request as ready for review July 28, 2026 20:31

milt requested a review from cliffcaseyyet July 28, 2026 20:31

milt added 6 commits July 29, 2026 17:03

added failing test on trigger matching

b753754

hierarchy-aware dispatch

f9704c7

delegate object lifecycle trigger matching to trigger dispatcher

e909d62

add methods to object subscription plan for descendent subs

5d6412d

sort subs by class depth

1220eb7

document subscription polymorphism

1907ad1

milt and others added 2 commits July 31, 2026 11:47

use full hla names for pitch compat

50372db

Merge pull request #43 from yetanalytics/object_update_trigger_sub_re…

3d7caa7

…work Concrete Classes and Descendent Subs

cliffcaseyyet reviewed Jul 31, 2026

View reviewed changes

Uh oh!

Conversation

milt commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cliffcaseyyet left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliffcaseyyet Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

milt commented Jul 27, 2026 •

edited

Loading

cliffcaseyyet Jul 29, 2026 •

edited

Loading