Thanks for the response! > 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. >
So don't use a session at all, or build a new Session class that implements the same interface as sqlalchemy's session? Are there particular parts of the interface that are depended on by other parts of the system? > 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. > In this design, session.update(model) would return the updated model. In theory, the whole point would be to eliminate that non-local behavior and move towards a more functional approach. On the other hand, it seems like this is one of those ideas that might not hold up in practice. Guess I'll have to experiment! Decisions made in the name of "separation of > concerns", sometimes critical but always very risky. > Point taken! 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.
