On Feb 8, 2010, at 4:12 PM, Kent wrote: > Ok, here are my questions: > > a) The merge eagerloads the order, along with its lines, but then, > directly afterward, issues two additional SELECT statements for the > two lines, even though these were already eagerly-loaded. That > surprised me. Why is that occurring?
I dont know. I would need more than code fragments to reproduce your behavior. (nor do I know what version you're on). It doesn't reproduce with a simple test. > > b) When I ask for the property .saleprice on the order line, another > SELECT statement is issued. Why does that occur when it was eagerly > loaded already? Same. If the value is in __dict__ it would not issue another load. > > c) In the case of line2, can SQLAlchemy be made to realize that part > of the primary key is not set and therefore there is no reason to > attempt a fetch from the database? It already detected this was a new > record during the merge. the "fetch for None", meaning issuing a fetch when the primary key was completely None, was resolved in a recent 0.5 version, probably 0.5.8. However, a partial primary key is considered to be valid. There is a flag on the mapper() called allow_null_pks=True which in 0.5 is set to False by default - it means that partial primary key is not valid. That flag is not in fact checked by merge() in this case, which is because the flag was already being removed in 0.6 by the time this fix went into place. The flag only led to confusion over and over again when users mapped to outerjoins, and didn't receive rows. Whereas nobody ever complained about merge issuing a load for None as a key - the issue was fixed because I noticed it myself. So you're the first person to ever complain about it, which is unfortunate since it may have led to a different path for the allow_null_pks flag. I dont like the flag very much since its obscure and nobody really ever used it unless I told them to directly. The only other way would be for the mapper to "guess" if nulls are allowed in the primary key based on the type of table/join structure its mapped to. So it depends on how upset this behavior is making you if I really need to find some way for it to differentiate between None-capable primary keys or not. > > Thanks in advance. > > Kent > > -- > 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. > -- 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.
