betodealmeida commented on issue #36379: URL: https://github.com/apache/superset/issues/36379#issuecomment-3608295433
Thanks @marianysilva! We're aware of this. @mistercrunch and I have offered to adopt the project under [our org](https://github.com/preset-io/), so we can keep maintaining it while preserving the project history and name. If we can't have the project transferred we'll likely fork it, since Superset has a deep dependency on SQLAlchemy. For context, today we use SQLAlchemy for basically 3 things: 1. Database connectivity. Databases can be configured via a SQLAlchemy URI, which is used to create a SQLAlchemy engine. In the past few years we introduced a better way of configuring databases via individual parameters, and if we adopted that for all databases, adding extra logic to the DB engine specs to build the connection, we could get rid of SQLAlchemy here. 2. Reflection. We use SQLAlchemy to abstract some reflection methods, like fetching the list of tables or column definitions. This one would also be easy to move to the DB engine spec, and would even give us some performance benefits (@Vitor-Avila implemented a custom reflection method for Redshift because the original one was too inefficient, and Amazon never accepted his PR). 3. Programmatic query generation (for charts). This is the most complicated part, though it probably shouldn't. We use SQLAlchemy core to build SQL from the query object from charts. This logic is old, untested, and complex, and I'm hoping we'll get rid of it in 2026. I've been cleaning up the chart generation flow for [semantic layers](https://github.com/apache/superset/issues/35003), and I'm hoping to introduce a simpler request object that we could use for easier SQL generation. I also hope to move SQL generation to the DB engine specs, so that different DBs can use different flow for SQL generation — string manipulation, `sqlglot` AST, or even SQLAlchemy core objects (which would be used only in DB engine specs that have a well supported SQLAlchemy dialect). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
