Introduction🗒️
web2py is a free, open-source web framework for Agile development that implies database-driven web apps; web2py is written and programmable in Python. web2py is a framework for full-stack; it comprises all the components a developer requires to build a fully functional web application.
web2py follows MVC (Model-View-Controller) pattern for running web applications. The model here is part of the application, which includes the logic of the data, the view here is a part of the application that helps render the data display to end-users, and the controller here is a part of the application that handles user interaction.
Legacy databases and keyed tables
Legacy databases are commonly referred to as a database that has been in use for several years and is unsuitable for modern apps and environments. The existence of a legacy database presents multiple challenges to an organization, according to the need to access and integrate the older data. A company may decide to leave the database and its applications if legacy data are required primarily as an archive.
Web2py can connect to legacy databases in some conditions:
The simplest way is when these conditions are met:
- Each table must have an unrepeated auto-increment integer field called id
- Records must be referenced, particularly using the id field
When retrieving an existing table, i.e., a table that web2py does not create in the ongoing application, we need always to set migrate-false.
If the legacy table consists of an auto-increment integer field, but it is not called id, still we2py can access it. Still, the table definition must declare the auto-increment Field with type ‘id’ (i.e., by using Field (‘...’,’ id’). At last, if the legacy table uses a primary key which is not an auto-increment id field, then it is possible to use a “keyed table”; for example:
db.define_table('account',
Field('accnum', 'integer'),
Field('acctype'),
Field('accdesc'),
primarykey=['accnum', 'acctype'],
migrate=False)
primarykey is a list of the names of the Field that makes the primary key. All primarykey fields consist of a NOT NULL set even if it is not specified. Keyed tables can only refer to other keyed tables. Referencing fields must use the format reference tablename.fieldname. The function update_record is not available for Rows of keyed tables.
At the time of writing, we cannot make sure that the primarykey attribute works with every existing legacy table and supported database backend. For clarity, we recommend creating a db view that has an auto-increment id field.
Distributed transaction
A distributed transaction is a database transaction in which multiple network hosts are involved. Commonly, hosts anticipate transactional resources, while the transaction manager is accountable for managing and creating a global transaction that encompasses all operations against such resources.
Let’s assume we have two or more connections to different PostgreSQL databases, for example:
db_a = DAL('postgres://...')
db_b = DAL('postgres://...')
In our models and controller, we can commit them concurrently with:
DAL.distributed_transaction_commit(db_a, db_b)
When fails, this function rolls back and raises an Exception.
In controllers, when one action returns, if we have two distinct connections and we do not call the above function, web2py commits them distinctively. This means there is a possibility that one of the commits fails and one succeeds. And this is prevented by the distributed transaction.
34+ registered 
