On Thu, Nov 2, 2017 at 3:09 PM, Max Rothman <whereswalde...@gmail.com> wrote: > I was poking around Elixir's Ecto, and I was curious whether it was possible > to apply their strict separation between data and operations to SQLAlchemy. > One could imagine an API where session.query fetches mutable, data-only > versions of models, and models are updated with something like > session.update(model), which would be a proxy for > update(Model).where(Model.id == model.id). In that scenario, the only > stateful element of the session would be the status of the current > transaction. > > Is this sort of thing possible? Can the declarative API be used without > binding model classes to a session?
The declarative API and the Mapper objects it creates have no dependency on a Session being present at all. So you're free to build a new kind of Session that doesn't use a unit of work, sure. > Can session state management be turned > off, or could the connection be used directly? It depends where you want to make the cutoff. You can build out this new ORM using Core where you'd have Connection and all that. If you want to still use Query then you'd have to subclass that also and provide an alternate loading scheme (called from _execute_and_instances()). I don't really see how this approach is *worth* it, after all if you just session.update(model), what about all the things which refer to it and for which it depends on that may not have been "updated". You have to hand-wire all that in your code, which would ultimately lead to inventing some new system of automating it all, which means you just reinvent the whole thing. SQLAlchemy even started with a little bit of this "separation" idealism, which is why it has this thing nobody uses anymore called "classical mapping" - the idea that the class definitions would know nothing about how they are persisted. Sounds great until you realize the class needs to refer to its own state and the attributes within that state are determined by the table schema. We used to have querying work as "MyClass.c.col == 'value'", e.g. the ".c." was there as a means of "separating" the "persistence" from the "object model". When we changed it to just be "MyClass.col", the library became massively easier to use and allowed the whole brilliance of "hybrid properties" that everyone now loves to come forth. If there were ever a SQLAlchemy 2, "classical mapping" as an option and "declarative" as only an "extension" would be at the very top of the list of things to go. Decisions made in the name of "separation of concerns", sometimes critical but always very risky. > > Thanks, > Max > > -- > 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 - 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.
