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 not the problem (if you can
>> call it that
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 not the problem (if you can call it
> that) that I'm describing here. I should double check to make sure the
> design
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
I can't talk about the Session aspect, but IMHO you should track each
object with a revision-id or revision-timestamp. that would allow you to
prevent race conditions on edits (you can ensure that an edit applies to
the right version), and your GUI can potentially just query the database to
de
(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
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
