Rick Morrison wrote: > > > 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.
I think you missed the part where I said that the object in question was already save()'d, so at any moment it could be flushed and the id magically filled-in. Once you save() an object, you never know when it will be flushed. > > "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. No, I strongly disagree. Once you save() an object, there are absolutely no guarantees about when it will be flushed (other than that it will happen the transaction is actually committed). An example: In sqlalchemy, if I create an object and save() it, it won't be flushed (yet. probably). If I then execute some arbitrary query (say, session.query(Something).filter(Something.c.name=='foo').all()) then sqlalchemy WILL flush that object I just saved! And that's the correct behavior because it would be nearly impossible for sqlalchemy to correctly determine if the object I just saved should be returned with the query. In other words, I never flushed, but it got flushed anyway. I'm not saying that sqlalchemy should always flush every object once you start touching any of its attributes. But for attributes that we KNOW need to be fetched, they should be treated exactly the same way that arbitrary queries treat Pending objects. I can't find any place where sqlalchemy makes any guarantees regarding the transition from Pending to Persistent state. Which is why I think that objects in the Pending state should function (to the best of sqlalchemy's ability) in as close to the same way as possible. Just some thoughts, -Adam Batkin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
