New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
query heuristic inspection system #3225
Comments
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: OK I think event-wise, we only should have "before_compile". This is the only place that we know what we're otherwise working with. then we need a query language to get at information within the query. Here is the QueryInspector:
this can then tell us about what's contained within, with the QueriesAgainst object:
how about a from_self() query? (or that we get from a union, etc)
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: OK next modification. we need to get at eager joins as well. so I think we should not use inspect() here, and instead, pass either the QueryContext itself or some inspection version of that directly to the event. The API here needs to allow us to get at joins that have been created so that we can add criteria to the ON clause of joins. Some system of affecting entities at the FROM level transparently, e.g. if the FROM element is the right side of a JOIN the criteria goes into the ON else it goes into the WHERE, is needed.
|
Michael Bayer (@zzzeek) wrote: use cases:
the use case for #1 has to be handled differently than the use case for #2, #3. I'm trying to find a simple, one-way-to-do-it-all approach here, but im not sure that's possible. if we already select from Foo and say WHERE RelatedBar == 5, we need to add .join(Foo.related_bars), and we may need the full capabilities of query.join() for that. For the vast majority of cases here, it's much easier to give the user a Query that they can just add things on towards. However, for eager joins, none of that works. eager joins are produced using Core-only techniques. I don't like giving the user two APIs, for the entity over here, you can use a Query, but then when it's joinedloaded, you have to use some totally different Core-only thing. but let's consider it's not avoidable. It would be:
so here's how we'd have to document this. Use compile_before_setup to make the query deal with additional entities that aren't currently there, as well as to add details about how primary entities are loaded. Use compile_after_setup to modify the criteria at which individual entities are selected. so #1 is compile_before_setup, #2 is compile_after_setup, #3 is compile_before_setup. what is the inspection system used in either of these systems? I think there have to be two of them. The questions we ask of these inspection systems have to work against a Query and QueryContext at the same time. Maybe when we say, "include_eager=True", we know to look at the QueryContext if its present (throw an error if that flag is used in the before_setup event). |
Michael Bayer (@zzzeek) wrote: if we need to alter the way a joined eager load works, that should be done with options. we can alter the |
Michael Bayer (@zzzeek) wrote: the heuristic inspection system applies to the Query at any time. the event is just one way that it can be used. it's a new feature that would be added post-1.0. |
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: this is an important feature to be roadmapped but not totally high priority. |
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: this is still a nice idea but there's no timetable to implement at the moment |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: this is a great idea but lots of work and there's no urgency or resources on the horizon for this. |
Changes by Michael Bayer (@zzzeek):
|
Migrated issue, originally created by Michael Bayer (@zzzeek)
given issues like #3223 and the openstack issues with model_query(), here's a sketch of an idea:
with this extension we'd need to identify specific use cases (since we see them all the time anyway) and add them to the docs of this extension as covered use cases. So the docs here need lots of recipes and they need to be tested.
The text was updated successfully, but these errors were encountered: