> Movie is attached to a Director or not. like the FAQ says, we choose > not to get into generating "events" from foreign keys being set. > which is not a "forever" rule, but if you look in trac there are about > 300 ORM issues open that I'd rather get resolved before I have the > time to consider the ramifications of a change like that.
I didnt'm mean to push you on that. I just wanted to understand how dangerous it is to implement in my application some sort of dynamic creation of the proper object and put in the relation. My application is a general purpose one (a GUI), that makes introspection of the mapper to make assumptions on what is needed. I *do* understand all the related problems that prevents you from doing that in SA now, but working with a GUI somewhat narrows the problems (no huge number of select - just one attribute at a time, no doubt on precedence between an already existent object and a new one defined by setting a FK) and on the other hand I'd like to offer a solution (again in my app) in the situation in which the present of 'delete-orphan' would be a problem and getting rid of it is not a choice. My (temporary?) solution relays on RelationProperty.local_remote_pair (that is not present in the API documentation) to see if the ColumnProperty I set, would impact on a relation that has cascade with delete_orpahn set. Is there any better way to get the relation involved in the change of a fk or is local_remote_pair just ok? sandro -- Sandro Dentella *:-) http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
