On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote: > > Which tests? > > modeltests/test_client/ClientTest.test_session_modifying_view > returns ok and after that everything stops... I have to kill the bash > session.
!?! Sorry, no ideas. Can you isolate the test that is failing by running the tests individually, rather than as a complete suite? > >Hrm... my gut reaction is that the model description shouldn't know it > >is separated across databases; this is a deployment issue, so it > >wouldn't be good to hard code deployment into the model. > > That's my feeling as well. I'm trying to keep my mitts off the existing code > as much as possible though, I guess one other option would be a property on > ForeignKey that it could set on initialization by looking at it's > rel.to._default_manager.connection and making sure it's > the same as the class the FK is defined on? The Model should probably be keeping track of the database it is on, rather than the field. The model base already tracks column names and the like; adding a database name wouldn't be out of place. Then, if a field references a model, you can compare the remote model's database name with the local model. > Would end up as: > list_of_fk_values = SELECT firstdb_class_id FROM otherdbmodel WHERE > lookup_field = 'whatever'; #run on the other db > and: > final_query = SELECT * from thisdbmodel WHERE pk_column in > (list_of_fk_values); #run on the main db Sounds about right. The devil is in the detail, though. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
