[sqlalchemy] Re: Limiting Relationship Depths

This section of the narrative dogs will help you configure the relationship as you want. https://docs.sqlalchemy.org/en/13/orm/loading_relationships.html In terms of API docs,

Re: [sqlalchemy] Listing all the tables that a query uses

On Wed, Jun 26, 2019, at 1:51 PM, Brian Maissy wrote: > Background: I have a bunch of materialized views (postgres) that are > dependent on each other. When I want to change one of them, I drop cascade it > (postgres does not provide a way to modify the query of an existing > materialized

Re: [sqlalchemy] Listing all the tables that a query uses

You and sqlalchemy never cease to impress. Thank you very much! On Wed, Jun 26, 2019, 22:14 Mike Bayer wrote: > > > On Wed, Jun 26, 2019, at 1:51 PM, Brian Maissy wrote: > > Background: I have a bunch of materialized views (postgres) that are > dependent on each other. When I want to change one

Re: [sqlalchemy] Re: Limiting Relationship Depths

Awesome, thank you Jonathan. I know I've read that at least 3-4 times, but I think I've been staring at the screen too much these days to actually read. I'll give it a go and let you know how it goes! On Wed, Jun 26, 2019 at 10:58 AM Jonathan Vanasco wrote: > This section of the narrative dogs

Re: [sqlalchemy] How to inspect filters

FWIW, I found a better approach to a similar problem was to create a dict/object I used to log metadata about the query I wanted... then build the query or analyze it based on that metadata. All the information is in the sqlalchemy query, but the execution performance a development time was

Re: [sqlalchemy] How to inspect filters

That's very interesting, Jonathan. Could you show me a quick example of that approach? I'm not sure I *need* to do that, but I think I would learn about SQLAlchemy from such an example and trying to understand it. On Wed, Jun 26, 2019 at 11:00 AM Jonathan Vanasco wrote: > FWIW, I found a better

[sqlalchemy] Listing all the tables that a query uses

Background: I have a bunch of materialized views (postgres) that are dependent on each other. When I want to change one of them, I drop cascade it (postgres does not provide a way to modify the query of an existing materialized view) and recreate it and all of its dependents (which are dropped