Hey,
Michael Bayer wrote:
[snip]
> well that is the part of the use case I don't understand. Why the
> "automagic" aspect of it ? and if there are dozens of target tables that
> have similar attributes, why not reduce the workload in a more boring way,
> like one that just adds the attributes after the fact:
>
> def map_my_stuff(parent, child):
> parent_mapper = class_mapper(parent)
> parent_mapper.add_property("children_editable",
> relation(..<figure it out from parent_mapper etc>..)
The answer would be that I hadn't considered that approach yet, but I
could indeed do try to do this at the mapping phase. I'm not terribly
familiar with the way mapping takes place yet, but this gives me a clue
as to where to start looking - thanks!
>> I've noticed that I need to expire the instances with relations very
>> often if something changes about the workflow status in one of the
>> related objects - it seems SQLAlchemy doesn't figure this out for
>> itself. Perhaps this is expected. I intend to post about this separately
>> after I've isolated this issue.
>
> I would suggest using a "dynamic" relation if you'd like the attribute to
> issue a SQL query on every hit. Using a "Dynamic" relation for the
> "core" relation can allow you to construct all of the alternate "views" at
> the class level without much need to muck about the mapper:
>
>
> class MyClass(object):
> @property
> def editable_children(self):
> return self.children.filter(Child.editable==True)
Yeah, this is like the property approach I was considering. To automate
this I'd need a way to determine Child automatically from the
self.children relation, and I hadn't gone into that yet.
> if the core "children" relation were non-dynamic, the same route can be
> applied:
>
> class MyClass(object):
> @property
> def editable_children(self):
> return
> object_session(self).query(Child).with_parent(self).filter(Child.editable==True)
>
> this approach would remove the need to dig around ORM internals
Oh well, at least I learned something about them. :)
> and would
> solve all the "stale data" issues too, assuming autoflush is turned on.
> SQLAlchemy's behavior of "caching" collections in the first place is
> fairly unique among Python ORMs (its more of a Hibernate thing) so this is
> the usual way that issue is addressed.
Thanks for the tip!
Regards,
Martijn
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
