On 1/4/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: > > This might be useful for tests for the database alteration > > functionality (which IMO we still have to provide though perhaps not > > for the 1.0). > > This is the part I am very interested in and using most of the time actually > :)
To expand on that a bit more: I think we need (at least for after the 1.0) two more sets of tests: (1) Database alteration. Similar to the datatype/constraint tests, we start with a model and create it in the database. Then we change the original model in one aspect, e.g. add a column, or change the size of a column or whatever. Then we ask the platform to alter the database and check what happens. To make the tests database independent, it is probably useful to compare the model read-back after the initial creation - adjusted according to the intentioned change - with the model read-back after the alteration. Or we could check the alteration SQL, though then the tests are database specific. (2) Reading and using of live databases. Here we should create the database using database-specific SQL (e.g. a test per native type as well as the constraints, default values etc.), then read it back, check this model and perhaps also insert some stuff and get it back (as the datatype tests do). But honestly, I think we should do this after the 1.0 because this looks like a lot of work ... > No problem. Curious how much you can get running (currently have 18 failures > and 3 errors) on the > datatypestest. I just discovered that MySql returns a default value for columns specified as not null, even if there was no default value spec. Strange database ... Tom
