> However, this is also true in SQLA -- if you make a separate query that >> happens to retrieve a record you have previously updated in the session, >> the previous update will first be flushed to the database before the later >> query -- so you still end up with the same number of updates as in web2py. >> > > Not i you deactivate auto-flushing. >
Yes, but it's on by default for a reason. You have to be careful about when you disable auto-flushing, or otherwise switch to manual flushing everywhere. > You will not get the benefit of auto-flushing for these > operations, obviousely, because you turned it off explicitly. > But it is EXACTLY in order to GAIN a benefit of Lazy-Updates ACROSS > NAME-SAPCES - that you temporarily turned it odd - which is something that > web2py CAN NOT DO. Ultimately, get a SINGLE-DATABASE hit in this example, > whereas using web2py you would get TWO hits. > Well, 3 database hits for the ORM, counting the 2 selects. But how do you know you can turn off auto-flushing in this example? What if a record was inserted in between the first function call and the second, and that's the record that needs to be updated in the second function? In that case, the second call will fail to make its update. Anyway, if you have a scenario like this where you know you're likely to be making multiple updates to the same record within the same web request, but you have to retrieve that record via separate queries in different parts of your code, I suppose you could build a basic identity map that stores queried rows by PK and does a lookup upon subsequent queries, just like SQLA. This doesn't require an ORM. I'm not sure you would want to do it automatically all the time, though, as there would be memory and processing overhead associated with keeping everything in such a structure, which would not be used most of the time. Also, it's true that in SQLA, if you do two separate queries that happen to >> retrieve some of the same records, it will still only hold one copy of each >> unique record object in memory. But it still needs to pull the duplicate >> data from the database and therefore hold it in memory for some time before >> releasing >> > > For this example, yes, but it is worth is because you are saving a > round-trip to the database, when compared to web2py. > You claimed that keeping only one copy of the object means you save memory -- I was just pointing out that at least the data used to create the object does in fact get duplicated in memory for a time. Furthermore, SQLA will keep *all* objects in memory throughout the session, whereas web2py may release objects when they go out of scope and are no longer needed. > But the Unit-Of-Work pattern, in conjunction with the Identity-Map, then > saves you ANOTHER hit to the database, in this case, when it is concluded > that no change is needed, THAT you CAN NOT do in web2py in this case, since > the two Rows object do not know about each other, and so the > back-to-previouse-value check thing can not be detected. > Does SQLA do a back-to-previous-value check -- I haven't seen anything about that? Anyway, at best that gets you down to 2 database hits, assuming you can solve the flushing problem (see above). Anthony -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
