On Tue, May 28, 2019, at 12:03 PM, Jonathan Vanasco wrote: > > > On Tuesday, May 28, 2019 at 9:10:19 AM UTC-4, Chris Wilson wrote: >>
>> During initial load one can use a global session object, >> ** > > You should not do that. Global sessions are widely considered an anti-pattern. additionally, running SQL inside of a TypeDecorator is not the intended usage, as well as using ORM features inside of a TypeDecorator is also not the intended usage. > >> I have discovered a limitation of TypeDecorators (custom column types): any >> one that uses the database (e.g. to load objects serialised in a custom way) >> has no way to know which database session to use. > While TypeDecorators are designed to offer control on how data is > encoded/decoded, they aren't really designed to do what you're attempting > (bootstrap an ORM relationship into a column, instead of a table). This is > the first time I've seen anyone try to do this, and I am a long time abuser > of SqlAlchemy myself. > Mike or Simon may have other suggestions, but my immediate thought is that > you can quickly accomplish what you're trying to do by just having a > TypeDecorator for `.cat_ids` serialize/deserialize a list of ids, and then > have a python @property for `def cats(self):` perform the sql needed to turn > `self.cat_ids` into `self.cats`. You'd be able to determine the session for > the actual object via `object_session` > > > @property > def cats(self): > if self._cats is None: > if self.cat_ids: > _session = *object_session*(self) > self._cats = _session.query(Cats).filter(Cat.id.in_(self.cat_ids)).all() > return self._cats yup, use a @property, this could work with the load/refresh events (see https://docs.sqlalchemy.org/en/13/orm/events.html?highlight=load#sqlalchemy.orm.events.InstanceEvents.load ) which was my first idea but the @property is possibly better since it's very simple. There is also the issue of the bigger pattern that is in use here, why a denormalized list of integers would be stored in a single column and how that serves any purpose beyond what a regular association table would achieve. Assuming this is not a legacy schema, I would advise using regular relational patterns. > > > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/daddca0f-c413-45e2-94cd-3fdb53b89a3a%40googlegroups.com > > <https://groups.google.com/d/msgid/sqlalchemy/daddca0f-c413-45e2-94cd-3fdb53b89a3a%40googlegroups.com?utm_medium=email&utm_source=footer>. > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/258dcabb-0545-4c90-9881-9ed5474de487%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
