Logic Context makes visible key aspects of Logic Execution, it's a good idea to review that.
For instance, an inserted row (such as an Order) might be updated later in the transaction by Item logic. For the Order, the verb will be INSERT initially, then UPDATE as the Items are processed. But initialVerb will remain INSERT.
Indicates the verb initially executed on this row. Consider inserting an Order and several Items. The item logic will update the Order, but the Order can determine that it was initially inserted in this transaction. For example, you might want to bypass auditing logic when an Order is inserted.
These should be used with great care, because they can introduce some subtle and non-obvious dependencies between rules. Nevertheless, they can be useful in some scenarios.
User properties are only set for the duration of the transaction: as soon as the transaction ends, all user properties disappear. The next transaction, even for the same API key, will not see these values.
The value of a user property can be anything.
This will output the given message to the transaction's log, using the User Logic logger. There are two other variations of this method:
An Object Model is created for each Base Table when you connect Espresso to your database. This model is automatically updated (e.g., if you change the schema) when you reload your schema.
We use the term "object" to refer to the Java Script objects created as part of the Object Model. So, in Logic Demo, you will have Objects for
If you are using Multiple Databases, be sure to prefix your table name with the database name (e.g., main:Customer).
This will return single bean if found, null if not found, or throw an exception if not unique.