Q&A: What do I need to know about Memos when it comes to reports and test suites?

Q: What is a memo?

A: Memo(“Name”) is a lookup for contextual data that is passed along a process (such as a report build, or a test case).

Q: Where do memos come from in reports?

A: Any input parameter added to a report will produce a Memo with a name matching the name of the input. The input value can be accessed with the memo function, provided you don’t replace it with a new memos. Memos in a child report are made available to the parent report provided the parent report (Report Data Set) has input parameter names which match those in the child report.

Any data set can have memo rules. The results of the memo rule are accumulated into a list and the full list is placed in the memo and is available at any point in the report processing which is later than that data set.

The memo is constructed by applying the rule to each item in the data set. After the data set is fully loaded the memo is generated and added to the Memos collection. If the data set is query data set, then the rule applies to objects of the type identified by the query data set. If the rule is a report data set the rule applies to ReportRow objects.

Q: How do memos work in query filters?

A: Input parameter memos will necessarily be single-valued, and data set memos will necessarily be lists. As such, care should be taken when testing for values, as the results will vary according to the data, e.g.  an == test on a single value will might work when there’s only one item in the list but fail otherwise. The oddity where it may work on occasion is when the queried db field is itself a list. MongoDB uses contains/subset logic when comparing equality of an array property with a query value.

Consider the document: { a: [1,2] }. MongoDB will return this document for each of the following queries:

• a == 1
• a == [2]
• a == [1,2]
• a == [2,1]

... but not:

• a == [2,3]