Thank you for a quick response. I'll try it and I'll risk the possible incompatibility with the future release for now...
> actual session.delete()) if thats what you want. For one thing, if > you have an object A referenced by B as a parent, and a delete of B is > superceded by an update of just a timestamp, now B still has the > foreign key linking to A and will still show up as one of its children. I know that changing just a DELETE behaviour is not enough. Further I need to modify the SELECT behaviour in all possible places within ORM in order to eliminate all rows where 'remove_date is not null'. I've done this already in the methods .first, .one, .all and .count for know, placing there a hook from the MapperExtension (as a try-out) Could you give me a hint, what methods I need to 'hook' in order to change the way relations are populated? Then, although B has a foreign key to A, ORM would filter it out. I achieved such a functionality/transparency already with an Oracle database using VIEWS and INSTEAD_OF triggers. But placing this in ORM would make it DB-independent what I actually need, as I'm moving from Oracle to PostgreSQL. Thanks again, Andrzej --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
