[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
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) 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. >> > > I'm not suggesting it is the problem. What I am suggesting is that you're > very likely going to have a concurrency/race problem when there is a first > Session that lasts the scope of web requests, and a second session which > operates on a GUI (you're likely to have this on a web requests only > variant too). > Ah right, I misunderstood. Thank you for clarifying. -- 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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
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 doesn't expect to have concurrent edits on the same objects. > I'm not suggesting it is the problem. What I am suggesting is that you're very likely going to have a concurrency/race problem when there is a first Session that lasts the scope of web requests, and a second session which operates on a GUI (you're likely to have this on a web requests only variant too). -- 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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
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 Tuesday, 6 March 2018 21:10:03 UTC+1, Jonathan Vanasco wrote: > > 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 > detect if the revision changed or not. > -- 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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
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 detect if the revision changed or not. -- 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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
(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 methods. I think in trying to keep my example concise I left out too much detail to illustrate the potential problem I'm trying to avoid. To expand upon it, I can imagine a scenario where there are 2 branches, each with their set of leaves. In a scenario with some tabbed UI where both branches are "open" some editing happens on both but that the intention upon saving is to only save the current tab's branch but not commit any of the other changes. Based on your reply I do think that perhaps I'm trying to cover all my use cases too soon. Given that I do not know all the potential requirements it is not feasible to hide away the session completely. To continue on the expanded example; this is much easier to solve within a controller / presenter type layer that tracks which tab corresponds to which entity and then propagating changes to the corresponding entities based on the command(s) given. For now I think I will take a step back from the persistence layer and flesh out the remaining parts of the application. Once I get around to integrating it with a proper GUI I will finalize the design. Thanks again for the quick and detailed reply. -- 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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: How to maintain a tight transactional scope whilst allowing lazy loading / attribute refreshing?
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 http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
