Thank you. Maybe I did not explain well (English is not my first language): when I declare a dataclass to serve as business model (so something passed around the code, between libraries, layers, frameworks, etc.) - I don't want any ORM stuff in it. No matter if it is hidden in private/protected attribute. I just want ORM to be able to fill my dataclass after I fetch something from the DB without leaving a "trace" in resulting object and to "understand" dataclass when I perform insert/update (think of it as C structure). Its not a problem if I have to write this "adapter" for the needs of my project, just want to know if someone already did it and if not, what would be the recommended way.
Book I am referring explains exact problems we had when initial project layout was set: we dragged ORM in our business model and made business model aware of the ORM instead the opposite. Seems there are quite other people/teams made the very same mistake (otherwise there will be no book about it). It is not related only to SqlAlchemy but rather how people (mis)use ORMs in general and made their code hard to maintain (as we did because we don't know better atm). I think SA is great ORM, I use it, recommend it to others and will continue to do so - please don't take this as any sort of critique or nitpicking, I am just looking some clues how to resolve problems we encounter. Kindest regards On Tuesday, September 21, 2021 at 3:51:36 PM UTC+2 Mike Bayer wrote: > > > 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 sqlalchemy+...@googlegroups.com. > 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 sqlalchemy+...@googlegroups.com. > > 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 sqlalchemy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/69ec0ab7-dfe1-492e-b3fd-c99c29e17b7dn%40googlegroups.com.
