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.
