Discussion: tortoise.init() & TortoiseManager

I’m proposing start with an init handler like so:

def init(...) -> TortoiseManager
    ...

manager = tortoise.init(
    modules=['app', 'app.sub'],
    databases={
        'default': <some db handler>,
        'notes': <some db handler>
    },
    
)

# Models are discoverable (and introspectable)
manager.models →
[<app.Projects>, <app.sub.Notes>, <app.sub.Tasks>]

# Actions are discoverable
manager.actions →
{
    'tortoise': {
        'syncdb': { describe itself and parameters here },
        'makemigrations': ...,
        'migrate': ....,
        'info': ...
    },
   'app.sub': {
        'import_tasks': ...
    }
}

# Actions are executed
await manager.action('syncdb', param1=value1, ...)

# And then functionality useful for testing:
await manager.snapshot(...)
await manager.rollback(...)
await manager.teardown()

The TortoiseManager object would be a class that contains all the discovered models, and access to some management commands. (a bit like Django, but simpler at first).

Management action functions get the TortoiseManager object as an explicit parameter. The idea is to be able to do all introspection through a standard interface, to try and minimise incentive to access private functions.

We could do a tortoise shell command, which would be a wrapper around tortoise.init and TortoiseManager. We do it like that to allow any system it is embedded in to easily help manage it in their own tools.

For testing I would need the ability to tear-down, the tortoise environment, and handle both application-wide models, and test-local models. We can do something like:

from tortoise.testing import TortoiseTest

class TestThis(TortoiseTest):
    <some config here>
    ...

Where it would automatically build a test db if models are test-local (and tear it down after the tests complete), or use the globally configured test database. For our own testing we will probably use test-local models, and real application would probably use global models. So the use case should be optimised (ito convenience) for the global model use case, and test-local models can be a bit rough.

Automatic configuration will be quite important, so I propose a set of “sane” defaults, such as ability to use environment variables/config file to do init automatically. For that to work we also need to have the ability to initialise databases off a single string. eg. using URI schema like: https://github.com/kennethreitz/dj-database-url

Any comments/suggestions?

[andreymal]

Why is this issue closed? Personally, I’m not very comfortable that Tortoise has the shared global state. I would like to have an interface similar to that described in this issue.

@mijamo

that manager was probably created in the main file

You don’t need to create it in the main file. You can use a separate file (something like myapp/db.py) and implement a get_manager function in this file, or maybe a class with a manager field.

In fact, the reason I bumped this issue up is that I’m trying to make an application as an isolated class without any global state, but I can’t do it because many ORMs (including Tortoise) have a global state 😦

[grigi]

I think the result of the discussion was generally in agreement with you on points 1 & 2. For Point 3, there is some rudimentary routing available already, just look at examples/two_databases.py