Hi Everyone,
Sorry to bother you all, I haven't found anything on Stack Overflow or in
the documentation where users are only having ON CASCADE DELETE errors only
*intermittently*. If I retry the deletion it works. I have so far been
unable to figure out the conditions that leads to this
On Fri, Sep 15, 2017 at 12:14 PM, Conferency wrote:
> class Paper(db.Model):
> __tablename__ = 'papers'
> reviewers = db.relationship('User', secondary=paper_reviewer,
> backref=db.backref('papers_reviewed',
>
Awesome. Thanks everyone!
On Friday, September 15, 2017 at 7:01:11 AM UTC-7, Mike Bayer wrote:
>
> On Thu, Sep 14, 2017 at 7:08 PM,
> wrote:
> > I'm writing a handler for the "before_commit" event that requires that
> all
> > objects have primary key ids, and realizing
On Fri, Sep 15, 2017 at 10:55 AM, Julio César Gázquez
wrote:
> El 11/09/17 a las 14:52, Mike Bayer escribió:
>
> Please provide all mappings including the missing "Prestacion" class
> as well as exact information on which classes have their own tables or
> not.
SQLAlchemy (1.0.8)
On Friday, September 15, 2017 at 12:14:33 PM UTC-4, Conferency wrote:
>
> class Paper(db.Model):
> __tablename__ = 'papers'
> reviewers = db.relationship('User', secondary=paper_reviewer,
> backref=db.backref('papers_reviewed',
>
class Paper(db.Model):
__tablename__ = 'papers'
reviewers = db.relationship('User', secondary=paper_reviewer,
backref=db.backref('papers_reviewed',
lazy='dynamic'),
El 11/09/17 a las 14:52, Mike Bayer escribió:
> Please provide all mappings including the missing "Prestacion" class
> as well as exact information on which classes have their own tables or
> not.The code should be a mappings I can paste into a .py file and
> run to see the error you are
On Thu, Sep 14, 2017 at 11:35 PM, Philip Martin
wrote:
> Mike, thanks for the prompt response and all of your work on the library.
> Looking over the generic_repr again it now looks more general. While not
> according for positional arguments, probably something like
On Thu, Sep 14, 2017 at 7:08 PM, wrote:
> I'm writing a handler for the "before_commit" event that requires that all
> objects have primary key ids, and realizing that "before_commit" runs before
> the flush preceding a commit. Is there a way to have the handler run after
>
Could you pair a before_commit handler with an after_flush_postexec
handler? The before_commit one would set a flag to say that you are
committing, and the after_flush_postexec one would look for that flag
before proceeding.
Simon
On Fri, Sep 15, 2017 at 12:08 AM, wrote:
>
10 matches
Mail list logo