Yes. In other words: we do not try introduce problems for the purpose of solving them. ;-) In my opinion, the job of keeping a consistent state is with the database (and its acid model) not with the API.
On Tuesday, 30 April 2013 05:11:56 UTC-5, Arnon Marcus wrote: > > So, let me see if I get this straight - I'll describe how I understand > things, so stop me when I start speaking non-sense: > " > Web2py's DAL is stateless, and hens is not designed for object-oriented > style of data-modeling. Whenever you create an object to represent a > record, you are creating a statefull scenario - you now have to manage the > internal-state of that object, and keep it synchronized with the rest of > the transaction. By restricting the support of the DAL from using such a > pattern, web2py avoids a whole class of problems prevalent in ORMs that > are implemented via the Active-Record pattern. Rows are not comparable to > ORM-result-objects, as they are not supposed to be treated as statefull - > they are mere convenience-wrappers over a dictionary for attribute-access > usage for getting field-results. This goes well with web2py's execution > model, as it does not intend to be statefull, in the sense that models and > controllers are 'executed' on each request-session, and hence Rows are not > meant to be treated as objects that could persist in memory across > request-sessions. However, additional convenience-functions are present > in a Row object, for thread-local changes that can be done on it, without > it updating-back to the current transaction automatically. An > explicit-update is thereupon expected to be taken by the controller-code, > in order to update the changes for the current database-transaction. > Using the DAL, transaction-creation is handled implicitly by the > database-itself (if there are no active-transactions in the current > db-connection-session and then the connection is used), but committing of a > transaction is handled explicitly by the DAL, either automatically at > request-session-end, and/or manually by a call to do so on the > db-connection object. By designing it this way, web2py is leaving the job > of transaction-management to the database itself, and avoids many issues > that might arise if it would have tried to manage the transaction itself. > Given all that, the DAL's design is ill-suited for an OOP style of coding > the data-models, as whenever an object is instantiated, it becomes > statefull, and hence requires some mechanism to manage it's state - even if > it's lifetime is bound to a single transaction and/or connection-session - > a mechanism that web2py's DAL is not providing - by design - in order to > avoid a slew of issues that could arise from mismanaging these object's > state. The Row object may seem as though it has it's own > internal-state-management functionality, but this is only for short-lived > manipulations, for aggregating changes into a single update operation > within the transaction, for performance improvement. It's state-management > is not meant to be used like it is used in ORMs. > " > > Am I with you so far? > Anything I got wrong? > -- --- 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.
