Do we have any documentation or insight into which Logic Block actions operate in memory versus triggering database transactions? For instance, with the “Set Values” action, I would expect this to be handled in memory rather than persisting a value to the database for the current session — but I’d rather not make assumptions. Any clarification would be appreciated.
Hi Pablo!
I don’t know of any explicit documentation on this. You are right though, Set Values occurs in memory – EXCEPT for any data sources associated with an HD Structure. Those are constantly persisted to the database.
2 Likes
For the most part, the logic block actions that aren’t associated to record operations are done in-memory. To Brendan’s point, HD structures are an exception to this and have a bit of nuance.
Non-HD structures will initiate or contribute to a DB transaction when they need to make a request to the database, namely a fetch, insert, update, or delete. Other actions run in memory. New with 25.2 is a grouping of logic actions in logic block builder. This list (fetches) mainly consists of actions that will hit the database, with the exception of Fetch Temp Table. Some others have additional nuance or are cached after the first fetch, like Retrieve Module Settings.
This list of record actions mostly will hit the database (those highlighted), and some of the others have exceptions.
Most everything else is done in memory except for logic block calls, queue actions, and intelligence actions, many of which are situational.
If you have questions about anything in particular, please ask away! The list is too large to document fully here, but we can see about writing a more extensive note somewhere.
HDs are a different story. When working with an HD structure of type New or Existing, modifications to a data source in that structure are automatically persisted to simplify the development process. When setting values or calling another logic block with the HD structure, the current payload is typically saved in the NATE container, if there is one. This means that working with HDs can be performance-intensive, and it’s typically better to pass around Detail tables by themselves before committing all changes to the corresponding HD structure. I’m happy to go into some more detail on this or answer other questions regarding best practices, and you can also reference documentation under the Logic block best practices documentation, which has a variety of articles.
2 Likes
@ross I’m surprised you’ve included the Subtable actions in your highlight. Don’t those just update the parent record in-memory and Update Record must be called on the parent record for those changes to be persisted to the database?
For more info on HD best practices, see here.
For detail on the performance impacts of HDs that Ross alludes to, see here.
1 Like
More nuance! Yes - the subtable actions only modify the parent record at the time, strictly speaking. When working with a subtable main, these lead to an additional database action to update the separate table. Even though this is accomplished in the same trip to the database, these actions are worth slightly more consideration than the true in-memory actions because of their potential to impact performance, especially Delete when triggers or referential integrity are involved.
The same caveats are somewhat true for the Copy Attachments and Delete Attachments actions, and it’s worth noting that Build Dynamic Expression and Build Dynamic Sort are not a performance impact in and of themselves but do have significant impact on a fetch depending on how they’re built.
2 Likes