4 ms·

Actually, running integration tests against SQL RDBMS works really well. It might be a tad slow but the CI can easily handle that. We have Docker and all of tha

Actually, running integration tests against SQL RDBMS works really well. It might be a tad slow but the CI can easily handle that. We have Docker and all of that for this, and it works x-platform.

nicoburns 8y ago
Running the RBDMS with `eatmydata` (https://www.flamingspork.com/projects/libeatmydata/ https://www.flamingspork.com/projects/libeatmydata/) can significantly speed up tests in my experience. All of you're data is gone as soon as the process exits, but that doesn't matter for tests.
taeric 8y ago
Docker isn't really required for this. Any in memory db will provide good contract verifications. And a simple alpha/beta/gamma setup with the end database can get you the rest of the way there.
- tracker1 8y ago
  Docker can be a bit of a better option... Unless you're using the same database software for the in-memory operations as the actual deployment. Or aren't using many specific features the rdbms you have chosen (stored procedures, triggers, virtual fields, etc). Not that I'm a fan of triggers and prefer direct table access over SP, but virtual fields are GREAT during transitional changes. It also generally requires an abstraction between the DB variants.
  - taeric 8y ago
    Agreed. In the old world, this is what an alpha/beta/gamma environment could help test against. The in memory could be used to make sure your units and overall components were correctly specified. The actual installs of the DB software to isolated schemas were where you made sure you integrated with the DB correctly. That all said, I did not mean this to be that Docker doesn't provide some value. Just pointing out it is not a prerequisite. If that makes sense.
rodeoclown 8y ago
You can even do SQL DDL ALTER TABLEs in a Transaction on production, do the change, run smoke tests in a nested transaction that are all rolled back when complete, and if anything fails you roll back the DDL changes and are back where you started clean.
- tzs 8y ago
  Support for DDL in transactions seems to vary quit a bit between DB servers. In mysql (and I think also mariadb) ALTER TABLE cannot be rolled back, and also implicitly does a COMMIT on any in-progress transaction before altering the table. In PostgreSQL you generally can do ALTER TABLE in transactions, but there are dome restrictions or exceptions. If the alteration is to add a value to an enum, it cannot be done in a transaction. MS SQL Server seems to be OK with ALTER TABLE in the midst of a transaction, according to this article [1]. Oracle seems to be similar to mysql. Even the ones that support this well, like MS SQL Server, have restrictions on other DDL, such as creating indexes. I think I'd rather just assume no DDL in transactions and design my schema update procedure accordingly, rather than asking whoever is designing the new schema to try to limit themselves to changes from the old that avoid whatever statements whatever DB server we are using doesn't allow. [1] https://www.mssqltips.com/sqlservertip/4591/ddl-commands-in-transactions-in-sql-server-versus-oracle/ https://www.mssqltips.com/sqlservertip/4591/ddl-commands-in-...

Actually, running integration tests against SQL RDBMS works really well. It might be a tad slow but the CI can easily handle that. We have Docker and all of that for this, and it works x-platform.

nicoburns 8y ago

Running the RBDMS with `eatmydata` (https://www.flamingspork.com/projects/libeatmydata/ https://www.flamingspork.com/projects/libeatmydata/) can significantly speed up tests in my experience. All of you're data is gone as soon as the process exits, but that doesn't matter for tests.

taeric 8y ago

Docker isn't really required for this. Any in memory db will provide good contract verifications. And a simple alpha/beta/gamma setup with the end database can get you the rest of the way there.

tracker1 8y ago
Docker can be a bit of a better option... Unless you're using the same database software for the in-memory operations as the actual deployment. Or aren't using many specific features the rdbms you have chosen (stored procedures, triggers, virtual fields, etc). Not that I'm a fan of triggers and prefer direct table access over SP, but virtual fields are GREAT during transitional changes. It also generally requires an abstraction between the DB variants.
- taeric 8y ago
  Agreed. In the old world, this is what an alpha/beta/gamma environment could help test against. The in memory could be used to make sure your units and overall components were correctly specified. The actual installs of the DB software to isolated schemas were where you made sure you integrated with the DB correctly. That all said, I did not mean this to be that Docker doesn't provide some value. Just pointing out it is not a prerequisite. If that makes sense.

rodeoclown 8y ago

You can even do SQL DDL ALTER TABLEs in a Transaction on production, do the change, run smoke tests in a nested transaction that are all rolled back when complete, and if anything fails you roll back the DDL changes and are back where you started clean.

tzs 8y ago
Support for DDL in transactions seems to vary quit a bit between DB servers. In mysql (and I think also mariadb) ALTER TABLE cannot be rolled back, and also implicitly does a COMMIT on any in-progress transaction before altering the table. In PostgreSQL you generally can do ALTER TABLE in transactions, but there are dome restrictions or exceptions. If the alteration is to add a value to an enum, it cannot be done in a transaction. MS SQL Server seems to be OK with ALTER TABLE in the midst of a transaction, according to this article [1]. Oracle seems to be similar to mysql. Even the ones that support this well, like MS SQL Server, have restrictions on other DDL, such as creating indexes. I think I'd rather just assume no DDL in transactions and design my schema update procedure accordingly, rather than asking whoever is designing the new schema to try to limit themselves to changes from the old that avoid whatever statements whatever DB server we are using doesn't allow. [1] https://www.mssqltips.com/sqlservertip/4591/ddl-commands-in-transactions-in-sql-server-versus-oracle/ https://www.mssqltips.com/sqlservertip/4591/ddl-commands-in-...