All, First, must say this is based on state-of-the-art modern architecture of a different field: web libraries/frameworks, using the Virtual DOM.
First, the (Firebird) problem, but I'll abstain to comment internal details of DFW. About multiple Firebird metadata update (DDL commands) in the same transaction: - Is not recommended (at least by me) - Difficult (if not impossible) to develop right (without bugs) - Leaves things inconsistently (maybe with corruptions) if DDL and DML changes same objects - Is very restrictive on the allowed changes for the users At the same time, Firebird adopts the model of not leaving database with invalidated objects, so allow a single DDL command in auto-commit mode, more than restrictive, is a no option. When users want to change, say, a view, it needs in most cases help from tools that drop and recreate dependencies. Update metadata in production is very problematic. And in todays business, update in production is necessary. So what I call virtual metadata and how would it solve the problems: When a DDL command is issued, it will not change metadata directly. It will change metadata in a memory structure tied to the current transaction. It may read metadata from database as needed and change it (in memory structures). At commit time, changed metadata is validated (including validation with dependencies) and changes are applied to database. We may even allow concurrent transactions to change the same objects, as at commit time we validate and apply changes against the latest committed metadata. It's a simple approach, diif against initial state (same transaction), validate and applies to latest committed state. (This proposal does not deal with potential problems with metadata changes in read committed transactions.) It will allow database to go from a good state to a good state without restrictions, inconsistencies, corruptions and few locks. To make this work, we need to have two type of validations, validation phase 1 (v1, when DDL command is executed), and validation phase 2 (v2, at commit). At v1 we validate things like: - Cannot DROP a non existent object - Cannot ALTER a non existent object - Cannot CREATE an object that already exist At v2 we validate everything else: - No disallowed circular dependencies - State of changed objects are good - State of objects depending on the changed ones are good Adriano ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
