And keep in mind that the ORM alone in SQLA is over 20,000 lines of code (by contrast, the DAL is now around 10,000 loc). Even if we could get away with a modest fraction of that, this would be a significant undertaking. So, we really need compelling evidence that there are common use cases where this would make a notable difference.
Also, some of these features may not require an ORM per se -- it may be possible to add some of this functionality within the context of the DAL. Anthony On Tuesday, April 30, 2013 1:45:04 PM UTC-4, 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.
