IfcStore transaction operations

Hey all,
I´ve recently come across the the concept of transaction keys in the BlenderBIM plugin and I´m struggling to understand why it´s necessary. When I write my own code or plugins, I am able to omit this code without any perceivable issues. I know there's probably a very good reason why an operator is assigned a unique key, I just don't know what this is :(.

Here is the code i'm talking about:

@Gorgious - You seem to be a bit of a guru and also in my timezone, could you perhaps offer an explanation ? :)


  • Hehe no I'm no guru especially not concerning IFC shenanigans :) @Moult is the person with the answers here.
    The way I understood it, this step is necessary because it enables using the undo-redo system seamlessly, as well as keeping a record of what's been changed in the IFC file. (Try CTRL Z / CTRL SHIFT Z a few times with your code, and you may very well start experiencing weird behaviours)
    As you may know the BlenderBim addon doesn't store any valuable IFC information inside the .blend file, it's using special bridge operations to extract and update data directly from and to the .ifc file. You'll recognize this pattern if you have ever worked with some kind of database queries where the information needs to be retrieved from a distant database and updated on the client side.

    That being said, I think this paradigm is going to change with the refactor of the operator system Dion's been working on, but I don't know yet exactly how. :)

  • Thanks for the quick reply! Ok I think i somewhat understand now - If I'm correct it's the transaction_data that is stored with each operation allows the undo-redo system to function properly?

  • edited October 12

    This is a fun part of the code that I hope to touch as little as possible. I've tried to make it as simple as possible, but alas some parts are still tricky.

    Blender's undo system only keeps track of Blender data. This code allows us to have our own special undo system in sync with Blender. This is necessary since we work with IFC natively. For most Blender addons this is not needed - we are quite special. In the BlenderBIM Add-on it's more accurate to say we are a Blender based IFC authoring client. As such we have 3 undo systems we need to sync: Blender's undo, IFC's undo, and the BlenderBIM Add-on's undo (which primarily links Blender and IFC together).

    Each operation is assigned a unique key so that when you undo or redo, it can tell which operator's transaction it should rollback or commit. A unique key is necessary as you may call the same operator twice in a row.

    I don't expect this code to fundamentally change too much, but it will become simpler as the logic for top level operators and nested operator tracking is no longer necessary. This could mean less bugs, and less magic.

    More reading:




    Fun fact: IfcOpenShell is unique in the industry as being the only library to support transactioned IFC editing.

  • Thanks to both of you @Gorgious @Moult for taking the time to explain, I very much appreciate it!

Sign In or Register to comment.