Specifying a Set in an AgentQuery


(Leif Brown) #1

I’m building an agent to update an attribute field “$Dependents”.

“$DependentNotes” should be the Set of all notes linked in particular ways, plus the values of their “$DependentNotes” fields.

Setting the value is easy:

$Dependents=(links.inbound.requires.$Dependents+links.inbound.requires.$Path);

HOWEVER,

I’d like the agent not to update constantly, hence, the $AgentQuery needs to test

$Dependents!=(links.inbound.requires.$Dependents+links.inbound.requires.$Path)

Unfortunately, $Dependents is a Set, and the “links…” statement returns a List. These seem not to be equal. Even specifying “.unique” returns a List.

The following awkward workaround works:

$Dependents!=(links.inbound.requires.$Dependents+links.inbound.requires.$Path).intersect(links.inbound.requires.$Dependents+links.inbound.requires.$Path)

Surely there is a better way to handle the resulting List as a Set?


(Leif Brown) #3

Paul,
I think using a deduped List instead of a Set implies that the sequence matters, and so the agent would have to do extra work resetting an attribute over changes in order?

I can easily switch the data type to list, but it doesn’t seem as natural. Mostly, I was surprised I couldn’t find a “set(…)” equivalent to “list(…)”.

Thanks,
Leif


(Pat Maddox) #4

I just ran some quick tests and it seems as though if you have a Set on the left-hand side of ==, then it coerces the right-hand to a Set for the comparison.

For example, if you have:

  • $MySet = foo;bar;baz
  • $MyList = bar;foo;baz;foo

then $MySet == $MyList is true, and $MyList == $MySet is false.

So I’m a bit surprised that your code doesn’t work. That said, I’ve encountered plenty of surprises in Tinderbox action syntax.

My approach is to begin by hard-coding values and gradually replace them with expressions. For example, I might change the $AgentQuery to:

$Dependents != ("foo;bar;baz" + "bar;foo;baz;foo")

in some cases it’s possible that the hard-coded value works and the expression doesn’t (some expressions need extra parentheses) so I find it easiest to isolate each piece and build up to the final expression.


(Pat Maddox) #5

In this particular case I think you might be getting thrown off by the fact that agents work on aliases of notes. I created a test document and when I changed the query to

$MySet != (links(original).inbound.requires.$MySet + links(original).inbound.requires.$Path);

and the action to

$MySet = links(original).inbound.requires.$MySet + links(original).inbound.requires.$Path;

then it works as expected.


(Mark Anderson) #6

Links & aliases have some behaviours, strange against first assumptions, that only make sense through deeper use of the app. IOW - the existing behaviour is for a reason and can’t, for valid technical reasons, suit all use cases.

If joining (the output) of two links() actions I’d be tempted to also put each discrete links() call in parentheses to make it plain to Tinderbox that we’re merging two lists as opposed to some other data type:

$MySet = (links(original).inbound.requires.$MySet) + (links(original).inbound.requires.$Path);

It may make no difference, but it’s worth bearing in mind.


(Leif Brown) #7

Mark & Pat,
turns out the parentheses did make a big difference. I was accidentally getting a string-concatenation. I wouldn’t have spotted it without substituting simple lists.

I’m not sure I want to spend the time figuring out exactly why, but I may have to, for future use.

Thank you, all!