Agreed, you'd never do it this way. First of all, you have the ID already, so why would you use 'getItemByName'. Second, the getItemByName is flawed, it will return a set, not a single row. Third, if you are selecting anything, before you perform an action on it, you should at least verify that you have records to work on. Fourth, if 'setItemName' is an internal function, then you wouldn't want it to call update_record since you may have other updates that need to happen.
Developer stupidity is a problem, but you aren't going to solve that with code. On Tuesday, April 30, 2013 10:45:04 AM UTC-7, Anthony wrote: > > "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.
