> > "What are the benefits?" You should ask?
> Well, there are performance-improvements with the caching mechanism, and > with the aggregation of operations - certain change-operations are only > pushed to the transaction-view, when they are actually needed, or at the > end of the transaction. > I suppose there could be in some cases, but to avoid multiple updates to the same record, you can apply changes to the Row object and then call row.update_record() when finished. On the other hand, there may be cases where you want separate updates in order to trigger separate database triggers or DAL callbacks. Anyway, before investing lots of time building (and subsequently maintaining) a rather sophisticated ORM, it would be nice to know what kind of performance improvements can be expected and in what circumstances. In other words, how often do cases come up where the DAL is much less efficient than SQLA, and how difficult would it be to write equally efficient DAL code in those cases. Lastly, the main benefit is automatic-handling of caching and ordering or > operations, that the developer no-longer needs to take care of himself. > The benefit is not just for simple-data-modes, on the contrary - the more > complex the data-mode, the more this becomes beneficial, as the > automatic-detection of relationship-dependencies, and auto-cascade of > operations, can both save brain-cycles from the developer trying to hold > the whole schema in his head and make sure he pushes things in the correct > order, and also prevent human-errors that can mess-up the database in cases > that constrains are insufficient, and the developer overlooked some > relationship-dependencies and was using stale-data without knowing it. > Do you have an example of the above (i.e., where use of the DAL is complicated and prone to error but SQLA handles things automatically)? > For example, lets take the following code: > > def setItemName(id, name): > row = db.item[id].select() > row.update_record(name=name) > > def getItemByName(name): > return db.item(db.item.name==name).select() > > id = 42 > ... > row = db.item[id].select() > row.name='some name' # or row[name]='some name' or row.update(name='some > name') > ... > def setItemName(id, 'some other name') > .... > getItemByName(row.name) > > As you can see, the last function-call would either fail, or silently > return something other than what was asked for. So, obviously you wouldn't do it that way with the DAL, as that isn't how it works. But how important is it to have this pattern? Once you've finished manipulating the record, you can do row.update_record(), and then any subsequent select will see the changes. It seems like this would be useful only if you need to do a read in between two separate updates to the record and you need the read to see the first update (and for some reason you can't just look at the existing Row object itself). Is this a common enough use case to justify replicating the SQLA ORM on top of the DAL? Do you have a real-world example where this would be a critical feature? 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.
