cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: Jenkins builds
Date Tue, 17 Jul 2012 23:41:28 GMT
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

Mime
View raw message