> Having to > call flush before doing anything that might require the ID seems > excessive and too low-level for code like that.
Why? To me, having to work around the implications of an implicit persisting of the object for nothing more than a simple attribute access is much worse. For example, I have code that examines the instance id attribute of such objects to determine, for example, whether an item discount needs to be recalculated (not saved) or a differential discount needs to be calculated (item already saved). It's natural to simply examine the PK attribute to see if the item is persisted to make the decision. In this case, an object.is_saved() method could stand in, but imagine passing your object instance to some other Python function that just happened to sniff around attributes -- such behavior could cause the item to flush() without explicit permission? Yuck. > "As far as the application is concerned, objects in the Pending and > Persistent states should function identically." To me, this is a fallacy of how ORMs work, and ignores the particulars of what happens, or what could happen, during a database save round-trip. You could have default columns. You could have triggers. Your could have DRI violations. The database engine could do implicit type conversion. You simply cannot expect an unchanged object on a round-trip to a relational database in a real-world case. To always expect this is to invite huge complexity issues that have been the downfall of other ORM attempts. For pure unchanged round-trip behavior, you want a real OO database, not an ORM. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
