Charles Duffy wrote: > So -- one already needs to process deferrals based on > relations. What's needed to support arbitrary keyword arguments (many > of which will refer to other tables and their columns) is a reference > type which also triggers deferrals and can be found even if nested > as a parameter to an argument to a relation (or a list member in a > parameter to an argument to a relation!), or if mentioned somewhere > inside __mapper_args__ (a new mapping entry I'm creating for holding > extra arbitrary arguments). During processing, the reference objects > are all looked up and replaced with actual table/column references. > > Before I go and implement the deep-search-and-replace code to do it > this way, does anyone see a better approach?
Thanks to Mike's latest changes in the SQLAlchemy core to allow for deferred mapper compilation, a lot of the checking in ActiveMapper is no longer necessary (basically, the second loop inside the process_relationships() function). You should be able to remove this particular section of the code to simplify things a bit. I personally don't think supporting arbitrary keyword arguments is a good way to go for the very reason you describe above. Its far more difficult to detect deferrals if you have no idea which keyword args being passed in that might contain references to classes that have not yet been processed yet. Realistically, if you add individual support for the important keyword arguments, you can piggyback on top of the existing deferral code in process_relationships() and add some checks that will trigger deferral if one of the new keyword arguments refers to a class that does not yet exist. Let me know if I can be of any more help. -- Jonathan LaCour http://cleverdevil.org _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
