Hey, Michael Bayer wrote: [snip] > For the next go-around here, assuming this is all still not working > for you can you please provide an example of what the additional > "filter" does exactly ?
Oh, it was already working for me (with the hack as described with backref and such, earlier in this thread). I just looked for a better way, but the suggestions I got initially had some issues. What it does is filter on a workflow status. I.e. I want a number of relations, one of which shows all related objects, the other one restricts by some status of the target. This way I can navigate an object graph and only see, say, published items, or items that can be edited, by following the right links. I.e: zoo.animals # all animals in the zoo that have been 'published' zoo.editable_animals # all animals in the zoo that can be edited or have been edited zoo.archived_animals # all animals the zoo had once but have been removed zoo.all_animals: all animals above, i.e. the automatic relation I realize that this is unusual; normally one cannot expect any particular column to be present on the target such as my workflow status column, so it makes sense to spell it out explicitly in the 'relation' logic. I still think that even there having to actually make the auto-generated join explicit as soon as you want to add an extra criterion requires a bit of extra work and thought that might be preventable, but I don't think a solution to that would have helped my case. I'm still thinking about alternate strategies to reach the same effect. Properties for the alternate extra filters would be one option, but I'm not sure whether the property implementation can be made general enough to find the target table very easily either. An alternative idea I had was to create a special collection class that knows how to do such additional restrictions (perhaps a bunch of methods on them. 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. > at this point you're looking for a subclass > hook that is basically "augment_primary_join(self, > existing_primary_join)", since you're looking to have the "figure out > the joins" stuff done for you in exactly the same way it is now, but > you want to have a say in changing the final product. that's a > pretty arbitrary looking hook. Sure. Again, I'm not asking for a hook, I just tried to make it work but wasn't very happy with the result, so I thought I'd bring it up to see whether there was a better way. And then we got into a bit of a discussion. :) 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 -~----------~----~----~----~------~----~------~--~---
