On Mon, Sep 20, 2021, at 11:40 PM, Nikola Radovanovic wrote: > Thank you, > I am reading Architecture Patterns with Python > <https://www.cosmicpython.com/book/chapter_02_repository.html> and trying to > find a way to refactor our code to become maintainable. However I noticed > that even with mapped dataclass there are problems like the one mentioned > here <https://github.com/cosmicpython/code/issues/17> and proposed solution > is to use *InstrumentationManager* you just mentioned, but even with this > approach resulting dataclass will be "linked" to ORM object via internal > attributes, defeating the purpose of Registry pattern proposed in the book.
the instrumentation manager lets you change how this "link" occurs and there doesnt need to be any attributes on the class. that said, I am not familiar with that book and if there is some aspect to dataclasses that causes them to fail if there is some instrumentation on them, that's a pretty serious shortcoming in dataclasses. > > Would it be OK to simply use dict objects as adapter between dataclass and > ORM? I proposed using a weakkeydictionary, so if that's what you mean, then yes. again i am not famliiar with that book and im not really sure how code is not "maintainable" if it has some private attributes on it. seems pretty off. > > Kindest regards > > On Monday, September 20, 2021 at 4:04:05 PM UTC+2 Mike Bayer wrote: >> >> >> On Mon, Sep 20, 2021, at 5:04 AM, Nikola Radovanovic wrote: >>> >>> Hi, >>> When decoupling business from ORM model, dataclass passed to SA's >>> imperative mapper *map_imperatively* will receive SA's internals like for >>> example *_sa_instance_state* and *_sa_class_manager*. >>> >>> I am wondering, what would be the best way to have "pure" dataclass, >>> without SA internals? First thing to come to my mind is to perform query on >>> SA *Table* and use dict/namedtuple to populate dataclass. Are there better >>> approaches? I am in particular interested how this approach will behave >>> with partial and composite updates? Any recipe to recommend? >> >> to accomplish that you use a registry, typically a weak-keyed one, where >> keys are the classes / instances in use and the values are the class >> managers and states. If you wanted to apply such a system to your classes >> you would make use of the instrumentation extension system: >> >> https://docs.sqlalchemy.org/en/14/orm/extensions/instrumentation.html >> >> there's also an example of it : >> >> https://docs.sqlalchemy.org/en/14/_modules/examples/custom_attributes/custom_management.html >> >> >> >> now as far as if you *should* do this. Absolutely not. The instrumentation >> extension system is a very old and almost never used corner of the API which >> I moved out of the main library some years ago due to its complexity. >> adding a weakref lookup to all class/state instrumentation lookups will add >> a palpable performance penalty to most ORM operations, and the >> instrumentation extension is likely not without bugs and regressions at this >> point. it was first created over ten years ago to suit the use case of a >> single user who was working with Zope security proxied objects. I've seen >> at least one other person using it, but overall i dont think it's worthwhile >> to spend lots of time going down tunnels like this; if your dataclass has a >> few attributes stuck on it, that shouldn't be a problem for any real-world >> situation. >> >> >> >> >> >>> >>> >>> Thank you in advance. >>> >>> Kindest regards >>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sqlalchemy/324223bc-695d-4479-be32-b1a7c73e8a76n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/sqlalchemy/324223bc-695d-4479-be32-b1a7c73e8a76n%40googlegroups.com?utm_medium=email&utm_source=footer>. >> > > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/3d3b6d37-d833-41a8-b414-2f41e7c601c3n%40googlegroups.com > > <https://groups.google.com/d/msgid/sqlalchemy/3d3b6d37-d833-41a8-b414-2f41e7c601c3n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/e5c15afe-3f82-4ab0-baed-1dcfe9f50b46%40www.fastmail.com.
