On 07/13/2016 02:22 PM, Seth P wrote:
That works!
Obviously I need to know that the joining field is called a_id, and I
can live with that, since in practice it's uniform. But I'm just curious
if there's an automated way to figure out which entity/column is related
to A. (There could be more
That works!
Obviously I need to know that the joining field is called a_id, and I can
live with that, since in practice it's uniform. But I'm just curious if
there's an automated way to figure out which entity/column is related to A.
(There could be more than one entity in q, though just one
On 07/13/2016 01:04 PM, Seth P wrote:
Thank you, as always, for the quick and detailed response.
With the join to the subquery that's on func.max(A.id), once you use
that function, the column loses it's "A.id-ness", because SQLA doesn't
know anything about func.max() and for all
Thank you, as always, for the quick and detailed response.
With the join to the subquery that's on func.max(A.id), once you use
> that function, the column loses it's "A.id-ness", because SQLA doesn't
> know anything about func.max() and for all it knows it could be turning
> it into anything.
On 07/13/2016 02:29 AM, Seth P wrote:
[Apologies for posting an incomplete version of this post earlier.
Please ignore it.]
If B has a ForeignKey (and relationship) to A (e.g. B.a_id -> A.id),
then I can write query(B.b_num).join(A) without specifying the
condition, and SQLAlchemy will figure
[Apologies for posting an incomplete version of this post earlier. Please
ignore it.]
If B has a ForeignKey (and relationship) to A (e.g. B.a_id -> A.id), then I
can write query(B.b_num).join(A) without specifying the condition, and
SQLAlchemy will figure out the join automatically. [See query
