me__ = 'right'
> id = Column(Integer, primary_key=True)
>
> parents = relationship(
> 'Parent',
> secondary=Association.__table__,
> back_populates='children',
> overlaps='child_links,parent,child',
> )
> parent_links
_populates='child',
overlaps='children,parents',
)
On Wed, Mar 9, 2022 at 4:50 PM Michael Merickel wrote:
> I think ultimately I want the overlaps config but reading through
> https://docs.sqlalchemy.org/en/14/errors.html#relationship-x-will-copy-column-q-to-column-p
at 4:33 PM Michael Merickel wrote:
> It's probably worth noting I can narrow it down to a single warning with
> the following snippet and it's still unclear to me how to resolve this:
>
> class Association(Base):
> __tablename__ = 'association'
> left_id = Column(Foreig
an be used to isolate the columns that should be
> written towards. To silence this warning, add the parameter
> 'overlaps="parent"' to the 'Parent.children' relationship. (Background on
> this error at: https://sqlalche.me/e/14/qzyx)
On Wed, Mar 9, 2022 at 4:31 PM Michael Mericke
I have looked at the couple examples in the docs (many-to-many, and
association table) and have noticed that my codebase has a slightly
different pattern which is causing warnings when upgrading to 1.4. I'm
trying to figure out the best pattern to accomplish what I've been doing
which doesn't
Well it looks like if I use column objects in a dict then it works out. For
example:
...insert({Event.start_time: datetime.utcnow()})
On Tuesday, December 22, 2020 at 2:16:23 AM UTC-6 Michael Merickel wrote:
> Is there a way to make the following insert statement work by changing
> som
Is there a way to make the following insert statement work by changing
something in the Event object's definition? Note I've simplified the
example, the reasons for using the core constructs in the first place are
to use postgres ON CONFLICT directives with it otherwise yes I could simply
use
If you look at the pyramid-cookiecutter-starter [1] the integration
modifies the env.py file to load the url from the app settings instead of
the alembic section of the ini. This allows you to put a copy-pasta
[alembic] section into the file which points at the migrations/slug
format/etc and
I think the basic idea is to create a database and codebase in the state of
the target revision. Then autogenerate a migration from nothing to that
revision - just like you would do when starting to use alembic from an
existing schema. From there you can change the slug on it so that it works
as
Presumably you do not have the pyramid_tm tween active in your pyramid
configuration which will perform commits at the end of requests:
config.include('pyramid_tm')
If you are running a script, you'd want to do your database actions inside
of a tm block:
with transaction.manager:
Mike, thanks for the clarification. I never noticed that particular
implication of the default cascade!
On Mon, Apr 1, 2013 at 1:23 PM, Michael Bayer mike...@zzzcomputing.comwrote:
On Apr 1, 2013, at 2:10 PM, Michael Merickel mmeri...@gmail.com wrote:
I ran into a situation the other day
I ran into a situation the other day where I would create a new object but
copy over some properties from an earlier version of the object. To do
this, I first created the new object, then I queried the database for the
latest copy of the object, copied properties to the new object, then added
12 matches
Mail list logo
