Transaction Management

[gswifort]

I'm wondering if the @command decorator should always create a new transaction and abort it if the command fails. This would ensure that Db.TransactionManager.topTransaction() returns a non-null object. The get_block_reference function needs to add the object to the database, so it would probably be a good idea to add it to the current transaction.

[CEXT-Dan]

Absolutely not! This is the way .NET works and I don’t like it.

[CEXT-Dan]

It’s fine if you need to use a transaction in a library, as long as it does not return any live (opened) objects, and the transaction is out of scope from the user, returning ObjectIds is okay.

It’s funny though, you know I had a big part in writing the .NET wrappers for one of the companies that we support. Of course I was the one who had to debug support requests. It seems once a code base reaches a certain size, coders end up using live objects outside of a transaction, and they end up with very hard to find intermittent crashes.

When I started writing the Python wrappers, I wanted it to be ARX like, and not make the same mistakes .NET did. I think I even have a post somewhere where I wrote “Look ma, no transactions” 😁

[gswifort]

So is this approach okay?

1. @command starts the transaction

2. get_block_reference checks if the transaction exists, and adds the block_ref to the transaction (raises an error if the transaction doesn't exist).

   tmr = db.transactionManager()
   if tmr.topTransaction().isNullObj():
       raise RuntimeError("No active transaction found")
   tmr.addNewlyCreatedDBRObject(block_ref)

3. @command ends the transaction (or aborts).

[CEXT-Dan]

How about you make separate decorator CommandWithTransaction?

[gswifort]

I think this will only increase confusion. I don't see the advantage of this solution – if a given command doesn't add anything to the transaction, the transaction will close without doing anything. The user doesn't need to know that the get_block_reference function requires a transaction.

[CEXT-Dan]

Sorry, I don’t want transactions to be default, I really insist on this, you will have to find another approach.
Another option is to have @command(use_transaction = True), but the default must be False

[gswifort]

I don't understand this document

I've created four functions that could represent the path to deleting an object from the database - none of them work. Please help.

from pyrx import Db, Ge, command
from pyrx.ed.prompt import get_string


def create_line_db():
    db = Db.curDb()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    return db.addObject(line)


def create_line_msp():
    db = Db.curDb()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    return db.addToModelspace(line)


@command
def doit3():
    db = Db.curDb()
    line_id = create_line_db()
    tmr = db.transactionManager()
    tr = tmr.startTransaction()
    line_tr_obj = tr.getObject(line_id)
    line_tr_ent = Db.Entity.cast(line_tr_obj)
    db.addToModelspace(line_tr_ent)
    print(line_tr_ent.id().handle())
    tmr.abortTransaction()


@command
def doit4():
    db = Db.curDb()
    line_id = create_line_msp()
    tmr = db.transactionManager()
    tr = tmr.startTransaction()
    line_tr_obj = tr.getObject(line_id)
    print(line_tr_obj.id().handle())
    tmr.abortTransaction()


@command
def doit5():
    db = Db.curDb()
    line_id = create_line_db()
    tmr = db.transactionManager()
    tr = tmr.startTransaction()
    line_tr_obj = tmr.getObject(line_id)
    line_tr_ent = Db.Entity.cast(line_tr_obj)
    db.addToModelspace(line_tr_ent)
    print(line_tr_ent.id().handle())
    tmr.abortTransaction()


@command
def doit6():
    db = Db.curDb()
    line_id = create_line_msp()
    tmr = db.transactionManager()
    tr = tmr.startTransaction()
    line_tr_obj = tmr.getObject(line_id)
    print(line_tr_obj.id().handle())
    tmr.abortTransaction()


@command
def doit7():
    db = Db.curDb()
    obj_id = db.getObjectId(False, Db.Handle(get_string("Enter handle: ")))
    obj = Db.DbObject(obj_id)
    print(obj.isA().dxfName(), obj.isErased())

[CEXT-Dan]

I haven’t use transactions much, but I believe you have you think of them as undo markers

Undo begin
Do something 
Undo end

def create_line_msp():
    db = Db.curDb()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    return db.addToModelspace(line)

@Ap.Command()
def doit1() -> None:
    try:
        db = Db.curDb()
        tmr = db.transactionManager()
        #undo begin
        tr = tmr.startTransaction()
        
        line_id = create_line_msp()
        line_tr_obj = tmr.getObject(line_id)
        print(line_tr_obj.id().handle())
        
        #undo end
        tmr.abortTransaction()
    except Exception as err:
        traceback.print_exception(err)


@Ap.Command()
def doit2() -> None:
    try:
        db = Db.curDb()
        tmr = db.transactionManager()
        #undo begin
        tr = tmr.startTransaction()
        
        line_id = create_line_msp()
        line_tr_obj = tmr.getObject(line_id)
        print(line_tr_obj.id().handle())
        
        #undo end
        tmr.endTransaction()
    except Exception as err:
        traceback.print_exception(err)

[CEXT-Dan]

I think this way is more correct, not sure though

def create_line_msp(tmr : Db.TransactionManager):
    db = Db.curDb()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    id = db.addToModelspace(line)
    tmr.addNewlyCreatedDBRObject(line, True)
    return id


@Ap.Command()
def doit1() -> None:
    try:
        db = Db.curDb()
        tmr = db.transactionManager()
        tr = tmr.startTransaction()
        
        #undo begin
        line_id = create_line_msp(tmr)
        line_tr_obj = tmr.getObject(line_id)
        print(line_tr_obj.id().handle())
        
        #undo end
        tmr.abortTransaction()
    except Exception as err:
        traceback.print_exception(err)


@Ap.Command()
def doit2() -> None:
    try:
        db = Db.curDb()
        tmr = db.transactionManager()
        tr = tmr.startTransaction()
        
        #undo begin
        line_id = create_line_msp(tmr)
        line_tr_obj = tmr.getObject(line_id)
        print(line_tr_obj.id().handle())
        
        #undo end
        tmr.endTransaction()
    except Exception as err:
        traceback.print_exception(err)

[gswifort]

Now it works - as you showed, all I had to do was create a transaction at the very beginning

[gswifort]

I think this way is more correct, not sure though

If I understand correctly, the first method is probably recommended.

The recommended approach is to close() the object after adding it to the database or the appropriate container and store the ID that is returned to you. Right after closing the object, which commits it to the database, you can use the getObject() function to obtain a new pointer for your operations.

[gswifort]

Then add it to the most recent transaction using AcTransactionManager::addNewlyCreatedDBRObject() or AcTransaction::addNewlyCreatedDBRObject

PyRx does not have a Transaction.addNewlyCreatedDBRObject() method

[CEXT-Dan]

there is no AcTransaction::addNewlyCreatedDBRObject

[CEXT-Dan]

As a side note, I’ve seen ARX samples where people call AcDbObject::cancel if some previous operation fails. It’s probably not a good idea to mix transactions and cancel.

it maybe that cancel is more lightweight for undoing single operations

[gswifort]

For documentation purposes:

@command
def doit9():
    db = Db.curDb()
    tmr = db.transactionManager()
    tmr.startTransaction()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    line_id = db.addToModelspace(line)
    print(line_id.handle())
    tmr.abortTransaction()  # The line was NOT deleted from the database 
    # because it was created during the transaction but was NOT CLOSED before UNDO


@command
def doit10():
    db = Db.curDb()
    tmr = db.transactionManager()
    tmr.startTransaction()
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    line_id = db.addToModelspace(line)
    line.close()  # ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← 
    print(line_id.handle())
    tmr.abortTransaction()  # The line was deleted from the database 
    # because it was created during a transaction and was CLOSED before UNDO

[gswifort]

So it seems that using transactions in the @command decorator is quite safe - if the operation fails and the decorator calls .abortTransaction() all closed objects will be restored, even if they are not explicitly added to the transaction.

[CEXT-Dan]

I insist that its not part of PyRx though. if the user wants to use transactions, that's on them

[gswifort]

I agree - I'm not trying to convince you 😄

[gswifort]

Side note (applicable to transactions, but also to opening and closing operations):
Garbage is not collected until the generator is closed, so it's probably best to explicitly close objects in the generator.

def line_generator():
    db = Db.curDb()
    i = 0
    while True:
        line = Db.Line(Ge.Point3d(i, 0, 0), Ge.Point3d(i + 1, 1, 0))
        line_id = db.addToModelspace(line)
        # line.close()  # !!!
        yield line_id
        i += 1


@command
def doit11():
    db = Db.curDb()
    gen = line_generator()
    l1 = next(gen)
    l2 = next(gen)
    Db.Line(l2, Db.OpenMode.kForWrite)  # raises ``eWasOpenForWrite`` if it was not closed in the generator

[CEXT-Dan]

the question is whether calling makeLine won't take up those nanoseconds that you didn't waste on calling .close() twice

You’re probably right, I did not consider Python function call overhead.

[gswifort]

You’re probably right, I did not consider Python function call overhead.

Despite this, I guess you were right - on average 650 ns per object :)

import timeit

db: Db.Database = Db.curDb()

N = 500_000


def make_line():
    line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0))
    return db.addToModelspace(line)


@command
def doit13():
    db = Db.curDb()
    time = timeit.timeit("make_line()", number=N, globals=globals() | {"db": db})
    print(time)  # 4.028116899979068


@command
def doit14():
    db = Db.curDb()
    time = timeit.timeit(
        "line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0)); db.addToModelspace(line); line.close()",
        number=N,
        globals=globals() | {"db": db},
    )
    print(time)  # 4.355444799992256


@command
def doit15():
    db = Db.curDb()
    time = timeit.timeit(
        "line = Db.Line(Ge.Point3d(0, 0, 0), Ge.Point3d(10, 10, 0)); db.addToModelspace(line); line.dispose()",
        number=N,
        globals=globals() | {"db": db},
    )
    print(time)  # 4.327822899998864

[CEXT-Dan]

You have a fast computer!

[CEXT-Dan]

another case

Yes, garbage collection becomes weird in the case of exceptions. I won't be able to make the library 100% foolproof, just wanted to replicate the behavior of ARX using AcDbObjectPointer, and to maximize performance. The safest option is to use Ax space.

Speaking of Ax space, one of my goals is to replace the internals with C++, so stuff like this would be a bit faster. But it’s already kind of fast enough

def line_generator():
    db = Db.curDb()
    i = 0
    axdb = db.acadDatabase()
    axmodel = axdb.modelSpace()
    while True:
        line = axmodel.addLine(Ge.Point3d(i, 0, 0), Ge.Point3d(i + 1, 1, 0))
        yield line.objectId()
        i += 1


@command
def doit11():
    db = Db.curDb()
    gen = line_generator()
    l1 = next(gen)
    l2 = next(gen)
    Db.Line(l2, Db.OpenMode.kForWrite)

[CEXT-Dan]

I should also add, this type of pattern is not ideal from a performance perspective

Every call to Database.addToModelspace is expensive, as it has to open the BlockTableRecord for write, then close, and flush the graphics. In a sense, its behaving exactly like Ax space. Passing around lists of entities to modify, or addToModelspace would be much faster