[sqlalchemy] How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
*Context* I'm currently designing the business and persistence layer that is going to be used in various frontend applications (Web and standalone). To that end I've been trying to reconcile ORM entities with a tight session scope but I'm constantly running into the same issues. For web I haven

Re: [sqlalchemy] How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
First off thank you for the quick reply. I have seen those resources you linked a few days ago and it guided me partially to my current ideas. The RepositoryContext class is essentially the contextmanager example with some extra helper methods. I think in trying to keep my example concise I lef

[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
I didn't mean to include that whole message history and I can't seem to edit/delete it. My apologies. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See

[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
(Third time's the charm, I messed up my original reply) First off thank you for the quick reply. I have seen those resources you linked a few days ago and it guided me partially to my current ideas. The RepositoryContext class is essentially the contextmanager example with some extra helper met

[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
I recall coming upon a section about this in the SQLAlchemy docs, although I can't remember where exactly. It's not the problem (if you can call it that) that I'm describing here. I should double check to make sure the design doesn't expect to have concurrent edits on the same objects. On Tuesd

Re: [sqlalchemy] How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
On Tuesday, 6 March 2018 21:12:01 UTC+1, Mike Bayer wrote: > > On Tue, Mar 6, 2018 at 2:52 PM, KCY > >> wrote: >> > First off thank you for the quick reply. I have seen those resources >> you >> > linked a few days ago and it guided me

[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?

2018-03-06 Thread KCY
On Tuesday, 6 March 2018 22:30:46 UTC+1, Jonathan Vanasco wrote: > > > > On Tuesday, March 6, 2018 at 3:23:42 PM UTC-5, KCY wrote: >> >> I recall coming upon a section about this in the SQLAlchemy docs, >> although I can't remember where exactly. It's

[sqlalchemy] Testing against DB Connector IntegrityError?

2018-03-07 Thread KCY
In one of my tests I'm checking that a pair of (non primary) fields must be unique. This definition is done with: __table_args__ = (UniqueConstraint('entity_id', 'version', name= 'id_version_combined_unique'),) where `entity_id` is an INT column referring to a foreign id and version is a plain

Re: [sqlalchemy] Testing against DB Connector IntegrityError?

2018-03-07 Thread KCY
Examining the stacktrace more closely revealed that I made the mistake of checking for the error on the add but left the context of that error check before committing. I actually did it the correct way in my all my other tests so I'm not sure why I made the mistake at the very end. My apologies

[sqlalchemy] Re: Testing against DB Connector IntegrityError?

2018-03-07 Thread KCY
To clarify on my post just now: My problem was that I did with scoped_session() as session: # setup stuff with pytest.raises(IntegrityError): session.add(entity) session.commit() # This should be inside the raises context. So the syntax in the orignal post here is actual