On 18/07/12 3:33am, Andrus Adamchik wrote:
On Jul 17, 2012, at 2:54 AM, Aristedes Maniatis wrote:
Without written steps on how to run the tests, are we confident that all the
right tests are run before release?
We do have written steps: http://cayenne.apache.org/running-unit-tests.html
What I meant was... when you run the tests against sqlite they currently fail.
What level of failure is OK? Which errors can we ignore?
What level of compatibility are we expecting with sqlite? Do we have a document
on what is expected to work and what will break? I've never used it directly so
I don't really know its capabilities, but ideally we should have a list of
known issues.
Would we be able to disable some tests when running against sqlite so that the
others pass? Not sure how easy or hard that might be.
In our unit tests we have something called org.apache.cayenne.unit.UnitDbAdapter that makes a
clumsy attempt to sort out databases by supported features (individual tests would do "if !
adapter.supportsFeatureX() return"). It works for real DB's where the differences are not that
great. When half of the metadata is not available and half of the SQL spec is not implemented, as
in the case with SQLite, it just doesn't "scale" in complexity.
Yes. And the effects can be quite subtle. For instance, we just ran into a problem which
only manifests on MS-SQL not supporting DISTINCT on certain column types. Ideally Cayenne
should have "known" about this limitation, but we were able to work around it
easily enough by altering the model.
I guess going forward it would be good to have something annotation-based for instance. E.g.
placing this on test methods: @ExcludeDB("db1", "db2"), and then building a
report about feature compatibility based on these annotations.
Having said that, I really have no concern about SQLite. We let people read and
write data from it, but otherwise I could care less about it.
I agree. What it really means is that SQLite might work by chance, but we could
easily break it in new ways and never notice.
"Real" DBs is another story, we need to make sure that all (most) the tests
pass. So your idea of having Oracle, PostgreSQL and others on Jenkins is a great one
(although I suspect the infra won't be very excited about it).
Well, in theory we should be able to get MS-SQL running since that is
apparently available. The others, well, maybe infra would give us a jail to run
them in ourselves. Let me see.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
