Michael Hipp wrote: > I'm still struggling with the idea of the director and director_id > being in an inconsistent state until flush(). I'll *definitely* > have to remember that. Seems like it could lead to many hard to > find bugs.
Well, again, its not inconsistent. When you create a new `Director` and a new `Movie` and then relate them together by setting the movie's `director` attribute, neither object has been inserted into the database yet, and therefore they have no primary keys. Its completely consistent with what is in the database. Once you flush, the objects are updated to be consistent with what is in the database. Because you are dealing with an object-relational mapper, you should largely interact with relationships through the relationship properties themselves, and not through the foreign keys. This is just a general rule of thumb, and not a hard and fast rule. I hardly ever find bugs in my code that relate to this particular issue, because I generally follow that rule when using the ORM for creating or updating data. > In that middle block if I try to get rid of the Director by > setting director_id to None, the object never comes back into a > consistent state even after flush(). I guess the dictum is to > never-ever mess with the "director_id" thing and consider it > read-only? Well, you could certainly look at it that way, and it would definitely help you avoid those pitfalls. The ORM does its best to determine the state of the object, and by messing around with the foreign key you're probably just confusing it :) -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" 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/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
