Don't forget about SAVEPOINT handling! It can make things very messy in this case (BUT expected to work as part of the transaction logic from my point of view). Lock should be applied in case of altering, parallel altering should be not allowed. (same as update a record, instant lock conflict error at command execution time, not commit time (even when different values are updated))
On 2017.01.18. 11:09, Dmitry Yemanov wrote: > 18.01.2017 12:38, Alex Peshkoff wrote: >> Currently with dfw we do have a lot of DDL errors raised at commit time >> i.e. it's not a regression. > True, but only because the actual work is performed during commit. If we > claim that DDL changes are applied immediately, but error is thrown at > commit, this looks weird. Especially if we find a way to allow mixed DDL > and DML - imagine ALTER TABLE and subsequent UPDATE both executing OK > but failing at commit because of the metadata conflict. > > > But don't forget that under > > normal circumstances such conflicts will be very rare. > > I would seriously question the need to allow concurrent DDL against the > same objects. This is simply not the way people work with the relational > databases. I'd rather lock the metadata being changed at the DDL time > and until commit. > > > Dmitry > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
