On 01/15/17 21:00, Adriano dos Santos Fernandes wrote: > 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.
I like the suggestion in general but some details worth thinking more. > (This proposal does not deal with potential problems with metadata > changes in read committed transactions.) If it will cause serious troubles - well, we can deny DDL 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 Returning to 'allow concurrent transactions to change the same objects'. What if both transactions create same objects or any other phase 1 conflict? First committed wins? > 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 > PS. We had more or less same suggestion from Jim >10 years ago (well, no word 'Virtual' was said that time) but it did not go out of generic discussion phaze. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
