Re:Why The Clock is Ticking for MongoDB
by dragonwriter on Thursday April 17, 2014 @12:10PM
(#7604460)
> And I don't think an ALTER can survive in a transaction, i.e. it is not something that can be rolled back. It can be undone via another ALTER that is it's opposite, but it cannot be rolled back the way INSERT and UPDATE can.
It can in databases that use transactional DDL (and, really, doing so is part of the relational model, since part of that model is that metadata describing the structure of data is itself stored in relations and -- whatever the syntactic sugar layered over top of it -- can itself be manipulated with the same tools that regular data is manipulated with.)
Having the DDL be described relationally is only incidental. I would imagine rollback support to be highly dependent on how the storage engine works. It seems non-trivial to me, short of copying the entire table across the ALTER. And that doesn't sound scalable.
Re:Why The Clock is Ticking for MongoDB
by JonnieCache on Thursday April 17, 2014 @11:46AM
(#7604314)
postgres can rollback everything except advancing sequences, and dropping the whole DB.
Re:Why The Clock is Ticking for MongoDB
by wildmXranat on Thursday April 17, 2014 @12:03PM
(#7604412)
that is awesome and I admit to not knowing about that. I've been on MySQL and DB2 for some time.
If the database is small, then sure, schema changes are harmless. But if a database is in production with data shuttling in and out of it and has many records, then ALTERs are non-trivial.
And I don't think an ALTER can survive in a transaction, i.e. it is not something that can be rolled back. It can be undone via another ALTER that is it's opposite, but it cannot be rolled back the way INSERT and UPDATE can.