Michael Bayer (@zzzeek) wrote:

OK "the same" threw me off here, these aren't "the same"....but I think I know what you're referring to

Michael Bayer (@zzzeek) wrote:

okey dokey #2976 and ref 12ce2ed

Gabor Gombas wrote:

Sorry for the ambiguity - 0.8:

SELECT ... FROM c LEFT OUTER JOIN b b_1 ON b_1.id = c.b_id JOIN a a_1 ON a_1.id = c.a_id
SELECT ... FROM d JOIN a a_1 ON a_1.id = d.a_id LEFT OUTER JOIN b b_1 ON b_1.id = d.b_id

While 0.9:

SELECT ... FROM c LEFT OUTER JOIN b b_1 ON b_1.id = c.b_id LEFT OUTER JOIN a a_1 ON a_1.id = c.a_id
SELECT ... FROM d JOIN a a_1 ON a_1.id = d.a_id LEFT OUTER JOIN b b_1 ON b_1.id = d.b_id

Gabor Gombas wrote:

Eh, you fix the code faster than I can write a comment :-)

Gabor Gombas wrote:

Ah ok, that's an older thread. Unfortunately, innerjoin="nested" does not seem to work:

SELECT c.id AS c_id, c.a_id AS c_a_id, c.b_id AS c_b_id, b_1.id AS b_1_id, a_1.id AS a_1_id 
FROM c LEFT OUTER JOIN (b b_1 JOIN a a_1 ON a_1.id = c.a_id) ON b_1.id = c.b_id

sqlalchemy.exc.DatabaseError: (DatabaseError) ORA-00904: "C"."A_ID": invalid identifier

Gabor Gombas wrote:

SQLite does work with innerjoin="nested"

Michael Bayer (@zzzeek) wrote:

that issue is where the new bug here was introduced

Michael Bayer (@zzzeek) wrote:

but "nested" failing on Oracle, ho hum that looks wrong too, let me try that on postgresql

Michael Bayer (@zzzeek) wrote:

wow, the 'nested' feature generates bad SQL. I have to revisit what that feature is supposed to do exactly, separate issue from this.

Michael Bayer (@zzzeek) wrote:

heh. well no, slightly different but still pretty deeply the same issue... :)

Michael Bayer (@zzzeek) wrote:

• Fixed a regression caused by 🎫2976 released in 0.9.4 where
  the "outer join" propagation along a chain of joined eager loads
  would incorrectly convert an "inner join" along a sibling join path
  into an outer join as well, when only descendant paths should be
  receiving the "outer join" propagation; additionally, fixed related
  issue where "nested" join propagation would take place inappropriately
  between two sibling join paths.

this is accomplished by re-introducing the removed flag "allow_innerjoin",
now inverted and named "chained_from_outerjoin". Propagating this flag
allows us to know when we have encountered an outerjoin along a load
path, without confusing it for state obtained from a sibling path.

fixes #3131
ref #2976

→ 61384fd

Michael Bayer (@zzzeek) wrote:

• Fixed a regression caused by 🎫2976 released in 0.9.4 where
  the "outer join" propagation along a chain of joined eager loads
  would incorrectly convert an "inner join" along a sibling join path
  into an outer join as well, when only descendant paths should be
  receiving the "outer join" propagation; additionally, fixed related
  issue where "nested" join propagation would take place inappropriately
  between two sibling join paths.

this is accomplished by re-introducing the removed flag "allow_innerjoin",
now inverted and named "chained_from_outerjoin". Propagating this flag
allows us to know when we have encountered an outerjoin along a load
path, without confusing it for state obtained from a sibling path.

fixes #3131
ref #2976

→ 43663e7

Changes by Michael Bayer (@zzzeek):

• changed status to closed

Michael Bayer (@zzzeek) wrote:

OK. This morning I kind of thought 0.9.7 was just about ready, but with your pace, it seems not. How much else do you have today?