orator
orator copied to clipboard
Do not suggest to use orator.py configuration file for migrations
Hello,
I am new to Orator: I wanted to setup Orator with SQLite for a small project. When I arrived to migration, I read in the documentation:
For the migrations to actually work, you need a configuration file describing your databases. It can be a orator.yml file or a orator.py located where the orator command is executed, or any other yaml or python file (these must then be explicitely specified when executing commands with the --config-c) which follow the following requirements:
I choose to use the orator.py variant. Once I set up this file, migration was working and I kept moving on my project. However, when I launched my application, I got messages like:
Traceback (most recent call last): File "test_orator.py", line 3, in
from orator import Model ImportError: cannot import name 'Model'
So I guess this orator.py file is being considered the module file by my interpreter and that is why it didn't find the Model class in it.
A simple way to reproduce this issue is to :
- install orator via pip,
- create an orator.py file containing a database configuration for migration
- create a file test_orator.py trying to import Model from orator
- launch the test_orator.py
Maybe this behaviour comes from my configuration (I installed module as user mode with pip, or I don't have a _init_.py file at the root of my project). Anyway, if this behaviour is confirmed and the configuration of python/pip is in cause, maybe it would be nice to add a few lines about it in the configuration. Or stop suggesting to use a orator.py file. Or change its default name. Or maybe this comes from the fact that I launch orator from the root of my project (which led me to put this orator.py file at the root of my project), which might be a not recommended behaviour/configuration.
I hope this will help.
yeah this shouldn't work lol. If you put an orator.py module in your project it will break. Not sure how that made it to the documentation and tested. Can you point where it is showing this and i'll try to get around to fixing it
It took me a while to figure out why I got these import errors while it worked before my migration ^^' I read that on this page: https://orator-orm.com/docs/0.9/migrations.html In the paragraph where database configuration file is explained.
In out project, we use orator.py in migrations, but we didn't use the ORM feature.
I think that's why it is good in our side.
I made a similar mistake. As a new user of Orator and long time user of ActiveRecord (Ruby), I don't think Orator should support putting credential in a special Python file.
It's first of all confusing and counterintuitive, because you would expect that kind of file to have initialization logic or something. Instead, it just defines a DATABASES constant which you have to dig all the way into the migrations documentation to understand. Why is this not mentioned in https://orator-orm.com/docs/0.9/basic_usage.html#configuration ?
Here the configuration is exemplified with inline configuration, which is great for understanding, but it would be nice with a "recommended/best practice" example which also takes the orator binary into consideration.
Next reason is the load path problem. The file can shadow the orator library.
For me, it would make more sense to exclusively support the YAML file as the only way to declare credentials.
With such a decision, you can also simplify the initialization by defining a class method on Model.
Model.resolve_with("db/orator.yml")
which creates a DatabaseManager and set it as the resolver.
One thing that puzzles me is the need to explicitly link the Model and the DatabaseManager. Why can't DatabaseManager have a class level/default instance that you can work with and link to Model by convention?
e.g.
DatabaseManager.configure("db/orator.yml")
And then Model will use it unless explicitly told not to by calling set_connection_resolver with another DatabaseManager instance.
Hi! Any progress on this?
I'm interested in this because I'm trying to integrate Orator into a web framework. The framework defines a settings.py file for configuration, and my idea would be to pick up the DATABASES variable there and use it for programmatic Orator configuration (e.g. through DatabaseManager()).
My issue is that doing this would require passing -c settings.py to the Orator CLI for every command, which is quite cumbersome.
And even if I used orator.py for Orator-only settings, it wouldn't work because of shadowing issues others have already mentioned.
So, building upon what @nielsbuus said about using orator.yml as the exclusive source of Orator configuration, my suggestion is to allow orator.yml to have a top-level option, like python_module, whose value (a file path to a Python module) would be used by -c if not given.
For example:
# orator.yml
python_module: ./settings.py
What do you think?
+1 Any update on this?
I have migration working, as described here: https://orator-orm.com/docs/0.9/migrations.html
But can't get any ORM to work with the orator.py file there
Same problem here, seems there is a missing piece of documentation about how to configure models with yml file
This worked for me:
In [1]: from orator import DatabaseManager, Model
In [2]: import yaml
In [3]: config = yaml.safe_load(open('orator.yml'))
In [4]: db = DatabaseManager(config['databases'])
In [5]: Model.set_connection_resolver(db)