On Wed, Apr 14, 2021 at 1:19 PM Mike Bayer wrote:
>
>
> On Wed, Apr 14, 2021, at 11:45 AM, Mark Aquino wrote:
>
> Thanks. I’ll take a stab at this approach. To back up a little bit my main
> confusion is around why the association tables aren’t updating as expected.
> As I un
the additional logic to remove the
stranded chains that are left behind but not linked to any test_molecules
anymore. Am I doing something differently in my test_molecule configuration
that I'm just not seeing?
Mark Aquino
From: sqlalchemy@googlegroups.com on behalf
Hi Mike,
Sorry about the indentations.
I'm not sure I understand the changes you made to the script after delete
as it removes all test_chains, test_var_regions, and test_const regions
that are still referenced by the other test_molecules. The only way I've
been able to get the delete to work
I just wanted to clarify, the desire would be for the "test_var_region" and
"test_const_region" entities that are linked to other entities to remain
untouched and only to have their associations removed from the deleted
items. The output from the ORM indicates that the system is actually
Thanks. I ended up using the models in the alembic file instead of bulk insert
mappings. Your point is well taken about the caveats of the model being out of
date but in this use case (just seeding the database) there’s no risk.
Mark Aquino
From: sqlalchemy
is unable to know
how many rows containing the desired type are present when the mixer table
contains references to several different classes by using the id shared on the
base class.
Mark Aquino
From: sqlalchemy@googlegroups.com on behalf of
Mike Bayer
Sent
the same mixer
table, because they all share a primary key with BaseClass (and removing the
need to make explicit mixed tables for every subclass).
Mark Aquino
From: sqlalchemy@googlegroups.com on behalf of
Mike Bayer
Sent: Thursday, December 17, 2020 7:08:58 PM
It's okay, I misunderstood what to point to in the inherit_condition
argument. I pointed it to the right column and it's working now.
On Tue, Sep 8, 2020 at 9:37 PM Richard Damon
wrote:
> On 9/8/20 8:02 PM, Mark Aquino wrote:
> > I’m not using that FK for inheritance though. I’m just
So if I’m understanding correctly then the inherit_condition should be the
column mapping the subclass to the superclass? In my case TrackedEntity.id ==
Request.id?
Mark Aquino
From: sqlalchemy@googlegroups.com on behalf of
Mike Bayer
Sent: Tuesday, September
I’m not using that FK for inheritance though. I’m just relating one type of
tracked entity to another (it’s parent, basically). After I did this it
actually broke my code so it didn’t really work (it just temporarily got rid of
one error and caused a more complicated one)
Mark Aquino
I was interested in creating a generic helper function to get the
instrumented list associated with a "RelationshipProperty" for a Model,
you can get the relationship from
inspect(model).mapper.relationships.items(), but the relationship is just
the RelationshipProperty object and *not* the
I'd like to create a relationship that joins a table linked to a related
table on a model:
I have a Vessel class, a Well class, and a Batch class.
Vessel and Well are related via a FK on Well (well.vessel_id) but Batch is
a many to many relationship with Well, e.g.
Batch(Base):
id =
:
>
>
>
> On Mon, Mar 16, 2020, at 1:23 PM, Mark Aquino wrote:
>
> Unfortunately none of those recipes work for what I'm trying to
> accomplish, and the mapper just complains that there is no "unambiguous"
> foreign key column to map the two classes.
>
> N
ying the
> "entity_type" table, however all four will store essentially the same
> information, just in different formats.
>
>
>
>
>
>
>
> On Sat, Mar 14, 2020, at 9:55 AM, Mark Aquino wrote:
>
> Is it possible to create a relationship via the
Is it possible to create a relationship via the table name as the "foreign
key"? I tried playing around with the foreign and remote options and tried
utilizing what's described here:
https://docs.sqlalchemy.org/en/13/orm/join_conditions.html#non-relational-comparisons-materialized-path
but
I
“You can use a @property so that when you get back an A or a B object , they
seek to return either the column on A or the column on B.“
I believe you’re describing the behavior I currently have, I.e. if I query B
then I can get b.visible_id otherwise I get A.visible_id.
I see your point about
e for every child class table, although a.) i dont
know if you can do that and b.) it's less desirable to have duplicate
values in that column.
On Friday, February 14, 2020 at 12:55:47 PM UTC-5, Simon King wrote:
>
> On Fri, Feb 14, 2020 at 5:35 PM Mark Aquino > wrote:
> >
> >
e for every child class table, although a.) i dont
know if you can do that and b.) it's less desirable to have duplicate
values in that column.
On Friday, February 14, 2020 at 12:55:47 PM UTC-5, Simon King wrote:
>
> On Fri, Feb 14, 2020 at 5:35 PM Mark Aquino > wrote:
> >
> >
I have a polymorphic class structure like this, with a lot of classes
extending the parent class.
In reality I'm using a Mixin that declares the visible_id column and it's
defined with @declared_attr.cascading, but for simplicity:
class A(Base):
__tablename__ = 'a'
id =
19 matches
Mail list logo
