Michael Bayer wrote: > > On Dec 10, 2007, at 4:12 PM, Adam Batkin wrote: > >> 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). >> > > you can guarantee an object is flushed by saying flush(). or if you > just retrieved it from a Query, youre similarly guaranteed that its > flushed. whats the speciic use case you have that youre concerned > about ? nobodys ever had this concern before AFAIK. > >> 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. > > why is flush() not a guarantee ? it seems really simple to me...
Sorry, I should have been clearer. Obviously once you've actually flush()'d there are no problems, and the docs make it clear that a flush() does in fact ensure that everything transitions from Pending to Persistent. My mental model has always been that once you save() something, it will be at _least_ Pending, but might transition at any moment to Persistent. This is only important because in my opinion, once you save() an instance, if you then poke at it's id attribute, you probably shouldn't be disappointed if the id is suddenly not None (even though you never issued an explicit flush()). (for example if you issue a query that involves that table) Regarding the other e-mail you just responded to... >> I know for a fact that Hibernate does it this way (not that sqlalchemy >> has to do everything Hibernate does), and I can't imagine a use case >> where doing what's needed to retrieve database-generated fields on an >> as-needed basis would be considered incorrect behavior. >> > > ive never seen that one before, i.e. the id generator being called in > direct reaction to calling myentity.getId(). In our hibernate apps we > often check for the id being null in order to check if the entity is > persisted yet. if you only mean that hibernate generates its own IDs > externally to INSERTs, yes thats true. SQLAlchemy would not use that Here's what I have seen in Hibernate (at least on Oracle, and I assume Postgres would be similar, assuming db sequences are used for pk generation): Create an object, save it. No db activity yet. Call object.getId(). Nothing inserted, but you can see a value IS pulled from the database sequence. I should test Hibernate with mysql to see if it actually performs a full insert of the row. > 2. I can show you the less-than-public API we use to put "value > generation" callables on attributes, i.e. the same one that issues > deferred loads and lazy relation loads. this would be a little more > like the start of an actual feature. > 3. building on #2 would be some feature to SA called "eager-fetch-ids" > or something like that, which looks at the Column for a > DefaultGenerator that is executable (Sequences, for example, are > executable DefaultGenerator objects). it would probably just take a > list of keys and apply to any columns you want, not just pk cols. That'd be lovely. Although I don't generally use databases that lack sequences very often, perhaps someone who does would also find useful so it might be interesting to see what the implications of having to flush a whole object to the DB if a DefaultGenerator column is accessed after a save() but before a flush() (or implicit flush due to a query). -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 -~----------~----~----~----~------~----~------~--~---
