Thanks for the ticket 1681 consideration. Though my understanding of the software isn't strong enough to recommend (or understand) what you are suggesting in 1681, I can observe the behavior enough to wonder "why do we need to go back to the database again?"
> > > (Also, wondering if some databases allow a primary key to be null...) > > I've researched this in the past and they don't. I will look into > re-introducing "allow_null_pks" as a new flag "allow_partial_pks", > defaults to True, will be honored by merge(), you set yours to False. > this is 0.6 only. > Thanks for your consideration, it seems that would be beneficial for us. As a side note, though, if no databases allow this, why would we default to True instead of False? Does allow_partial_pks have additional meaning, such as "complain if the object only has part of the primary key set?" You mentioned the main thing was how this affects outer joins. Can you expand on how this might cause outer joins to return no rows? Is it because users still expected a row returned from the *other* tables, even though part of this key is null? (I don't want to make you go back through the effort of re-adding this flag if it might cause me unanticipated side-effects that force me to abandon it, so maybe pointing me to an example of the main complaint when setting it to False? I'd like attempt to rule out that it might affect me.) Thanks -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
