it has nothing to do with joined table inheritance, in your example,
your base mapper is already mapped to "preferences_union", so if you
provide an alternative selectable that has no relationship to that, it
does not see any of the required columns being provided. it's just
like if your
Awesome!
I like the second approach better for the exact same reasons.
Thanks so much!
Kent
On Thursday, April 13, 2017 at 1:50:40 PM UTC-4, Mike Bayer wrote:
>
>
> it has nothing to do with joined table inheritance, in your example,
> your base mapper is already mapped to
Suppose we have the documentation's example of *Concrete Table Inheritance,
*where
session.query(Employee).all()
produces this:
SELECT pjoin.type AS pjoin_type,
pjoin.manager_data AS pjoin_manager_data,
pjoin.employee_id AS pjoin_employee_id,
pjoin.name AS pjoin_name,
On 04/13/2017 10:24 AM, Kent wrote:
Suppose we have the documentation's example of *Concrete Table
Inheritance, *where
session.query(Employee).all()
produces this:
SELECT pjoin.type AS pjoin_type,
pjoin.manager_data AS pjoin_manager_data,
pjoin.employee_id AS
That was the first route I tried. with_polymorphic() seems to cater to or
assume joined table inheritance. When I pass a selectable, it always ends
up *joining *my base to that selectable instead of *using only my
selectable*.
My problem might be that I'm trying to take advantage of
Hello everybody,
I'm new to the community and write to post about a small component I've
been working on for the last weeks - which adds support for OpenTracing (a
standard for tracing and instrumenting distributed applications). This
small component works for both the Core and the ORM layers,