Terry Hancock wrote: > I disagree that transactions are bad for CAD -- they may have > a different semantic role and the needed granularity may be > different, but the need to roll data back to an earlier revision > is just as present in drawings as it is for code or financial > transactions.
Sure, but that's called source control. So you do need transactions, but for the entire database state, not on database operations. (This was certainly true at Cadence -- there was a thriving third-party market for handling source control on CDBA databases, and I never encountered any code which operated on the database in a transactional manner. OpenAccess did have some basic support for transactions, but I never heard of anyone using them.) Some kind of transactionality is needed for undo/redo, but this is usually done in a different (some might say "more efficient", others might say "hackier") method than how transactions are implemented for RDBMS (that I've dealt with, anyway). I suspect this can be attributed to two major factors: concurrent access is never an issue in such systems, and the number of database objects representing a given state is far larger than in, say, e-commerce. -- http://mail.python.org/mailman/listinfo/python-list