You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In using gino I tried to use the reflect, but it fails. I speculate this is because it runs as a default sqlalchemy function rather than a gino spinoff, but since it is a gino engine it fails. To Reproduce
Please provide a self-contained script to reproduce the bug if possible.
AttributeError: 'GinoEngine' object has no attribute 'connect'
Now for good measure, I tried a few other alternatives
fromginoimportGinodb=Ginodb.gino._item.reflect()
The result was the same.
I need to e able to retrieve metadata from the database without having prior knowledge of items in it. Things like all the available tables. All the columns in a specified table and so on. Gino does not seem to support these key features. I would have proceeded to do this with sqlalchemy, but seeing that I am already using gino(and gino engine) I cannot because sqlalchemy does not recognize gino engines hence features like reflect, inspect and engine.dialect.get_table_names are not available in gino.
Now there is the option of creating one sqlalchemy engine and one gino engine for the same database but then that seems counterintuitive.
All the fails stem from variation in function names like connect instead of acquire except for dialect.get_table_name which is completely unavailable
Environment (please complete the following information):
GINO: [e.g. 1.0.1]
SQLAlchemy: [e.g. 1.3.10]
Linux, PostgreSQL 10, asyncpg 0.21
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
Hmm the reflect() was not supposed to work - it was probably a bad idea to simply inherit and expose such SQLAlchemy sync methods without specification, but that ship has sailed.
I haven't tried but I do think this will be in a better shape for v1.4 as SQLAlchemy 1.4 will support async natively, and we could somehow get that for free. In other words, this won't be fixed in GINO <1.4.
As a workaround, I'd suggest using something like e = sa.create_engine(); loop.call_in_executor(None, db.reflect, bind=e) to solve your current problem, as I would assume reflection is not something that'll be called frequently in runtime, so asynchronous is not a top priority.
This was just an illustration of a major underlying problem with the gino API(which I am currently working to fix). Reflect is definitely not the best example to have used, however gino inherits certain classes from SQLAlchemy but because of the difference in API for the connection and engine of both of them, GINO will throw an error, which is as a result of the code itself within GINO and not any users fault.
I noticed this problem when trying to work with Gino dialect classes.
I do intend to make use of SQLAlchemy 1.4 and above in the future, but it will be also be nice to have an alternative: GINO, without having this problem.
Describe the bug
In using gino I tried to use the reflect, but it fails. I speculate this is because it runs as a default sqlalchemy function rather than a gino spinoff, but since it is a gino engine it fails.
To Reproduce
Please provide a self-contained script to reproduce the bug if possible.
result
Now for good measure, I tried a few other alternatives
The result was the same.
I need to e able to retrieve metadata from the database without having prior knowledge of items in it. Things like all the available tables. All the columns in a specified table and so on. Gino does not seem to support these key features. I would have proceeded to do this with sqlalchemy, but seeing that I am already using gino(and gino engine) I cannot because sqlalchemy does not recognize gino engines hence features like reflect, inspect and engine.dialect.get_table_names are not available in gino.
Now there is the option of creating one sqlalchemy engine and one gino engine for the same database but then that seems counterintuitive.
All the fails stem from variation in function names like
connect
instead ofacquire
except fordialect.get_table_name
which is completely unavailableEnvironment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: