How would I exclude an Odoo custom logging model from rollbacks?

Question

I'm creating a custom logging model in Odoo. Naturally, I'd like the model to be completely exempt from the typical transaction rollback behavior. The reason for this is, of course, because I don't want exceptions later on in my code to cause log entries to never be added.

Here's an example scenario:

class SomeModel(models.Model):
    def some_method(self):
        self.env["my.custom.log"].add_entry("SomeModel.some_method started running")
        ...
        raise Exception("Something went wrong...")

In this case, I want to create an entry in my custom log signaling that the method began to run. However, depending on logic later in the code, an exception may be raised. If an exception is raised, Odoo of course rolls back the database transaction, which is desired to prevent incorrect data from being committed to the database.

However, I don't want my log entries to disappear if an exception occurs. Like any sane log, I'd like my my.custom.log model to not be subject to Odoo's typical rollback behavior and immediately log information no matter what happens later.

I am aware that I can manually rollback or commit a transaction, but this doesn't really help me here. If I just run env.cr.commit() after adding my log entry it will definitely add the log entry, but it will also add all the other operations which occurred before it as well. That would definitely not be good. And running env.cr.rollback() before adding the log entry doesn't make sense either, because all pending operations would be rolled back even if no exception occurs later.

How do I solve this? How can I make my log entries always get added to the database regardless of what else happens in the code?

Note: I am aware that Odoo has a built-in log. I have my reasons for wanting to create my own separate log.

Answer 1

I've figured out a solution, but I don't know if it's necessarily the best way to do it.

The solution I've settled on for now would in this example be to define the add_entry() logging model method something like the following:

# If log entries are created normally and an exception occurs, Odoo will rollback
# the current database transaction, meaning that along with other data, the log
# entries will not be created. With this method, log entries are created with a
# separate database cursor, independent of the current transaction.
def add_entry(self, message):
    self.flush() # ADDED WITH IMPORTANT EDIT BELOW

    with registry(self.env.cr.dbname).cursor() as cr:
        record = self.with_env(self.env(cr)).create({"message": message})
        return self.browse(record.id)

# Otherwise the method would look simply like this...
def add_entry(self, message):
    return self.create({"message": message})

Explanation

1. I got the with registry(self.env.cr.dbname).cursor() as cr idea from the Odoo delivery module at delivery/models/delivery_carrier.py:212. In that file it looks like Odoo is trying to do pretty much exactly what I'm looking for in this question.

2. I got the self.with_env(self.env(cr)) idea from the Odoo iap module at iap/models/iap.py:182. It's cleaner than doing self.env(cr)["my.custom.log"].

3. I don't return the new record directly from the create() method. I'm pretty sure something wouldn't be right about returning a recordset with an environment whose cursor is about to be closed (because of the with statement). Instead, I just hang on to the record ID and then get the record in the current environment and cursor with self.browse(). Hopefully this is actually the best way to do this and doesn't come with any major performance issues.

Please don't hesitate to weigh in if you have any suggestions for improvement!

Important Edit (A Day Later)

I added the self.flush() line in the code above along with this edit. It turns out that for some reason, when the with statement __exit__'s and the separate cursor is committed, an exception can be raised when it tries to flush data.

The same thing is done at delivery/models/delivery_carrier.py:207. I'm not exact sure why it is necessary, but it looks like it is. I assume that flushing the data comes with some performance considerations as well, but I'm not sure what they are and right now it looks like they are unavoidable. Again, please weigh in if you know anything.