Ticket #1146 (closed defect: fixed)
sqlalchemy + sqlite autoload doesn't work in 1.0b1
| Reported by: | kkinder | Owned by: | anonymous |
|---|---|---|---|
| Priority: | low | Milestone: | 1.0 |
| Component: | Documentation | Version: | |
| Severity: | minor | Keywords: | sqlalchemy reflecttable autoload |
| Cc: |
Description
sqlalchemy's autoload table reflection doesn't work (at least with sqlite) in 1.01b. This is because metadata.engine is None at the time model is imported, which prevents sqlalchemy from inspecting the database schema.
To reproduce this bug, quickstart a project with sqlalchemy. Create a blank sqlite database with sqladmin sql create. Then, manually create a table in the database using the sqlite3 command.
Add that table to your model.py by doing, table = Table('table name', metadata', autoload=True)
You will get one of these when you try to run tg-admin shell:
Traceback (most recent call last):
File "model.py", line 8, in ?
x = Table('Albums', metadata, autoload=True)
File "build/bdist.linux-i686/egg/sqlalchemy/schema.py", line 138, in __call__
AttributeError: 'NoneType' object has no attribute 'reflecttable'
This is because, at the time of model's import, metadata.engine is None.
Change History
comment:2 Changed 5 years ago by jorge.vargas
- Priority changed from normal to low
- Milestone set to 1.0
Can you give a valid usecase in which you will be creating tables on the fly?
because at the moment your just using the tool in a wrong way.
if we can get a valid usecase then I can set this a as task and consider it a bug
comment:3 Changed 5 years ago by catherinedevlin
My guess would be that kkinder doesn't intend to create tables on the fly, merely wants TG to work with the tables that already exist in the database - which will nearly always be the case for work centered on existing databases. autoload=True is easier to code than hand-typing column specifications, and avoids errors, so it's a legitimate need; ("Legitimate" = "I had the problem, too")
After lots of websearching, I learned that calling turbogears.database.bind_meta_data() in the model.py file, immediately after imporing turbogears.database, fixes the problem.
So I wouldn't call it a bug or a defect, but something that documentation possibly should highlight, since the quickstart-generated model.py doesn't contain or hint at a bind_meta_data() call.
comment:5 Changed 5 years ago by jorge.vargas
- Component changed from SQLAlchemy to Docs
then please add it to http://docs.turbogears.org/1.0/SQLAlchemy?highlight=%28SQLAlchemy%29
comment:6 Changed 5 years ago by alberto
- Milestone changed from 1.1 to __unclassified__
Batch moved into unclassified from 1.1 to properly track progress on the later
comment:7 Changed 5 years ago by Chris Arndt
- Status changed from new to closed
- Version 1.0b1 deleted
- Resolution set to fixed
It's already in http://docs.turbogears.org/1.0/SQLAlchemy
I am not sure, but it doesn't sound like a bug to me but a reasonable behaviour