cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Firebird support
Date Wed, 12 Jun 2013 18:47:06 GMT

On Jun 12, 2013, at 9:18 PM, Miłosz Pigłas <milosz@archeocs.com> wrote:

> thank you for your help. Adapter is almost ready,

Great!

> but there is still one test case: org.apache.cayenne.access.NestedDataContext_DeadlockTest,
which fails. Test passes only if checking threads is delayed few second - probably firebird
performance is to low.

Yeah, don't worry about this. This test is not adapter-specific. 

> Test org.apache.cayenne.query.SelectQueryTest#testSelectLongIn(), ends with error because
of generated statement size and firebird limitations (http://www.firebirdfaq.org/faq299/).
Are such errors aceptable?

For other DBs we used UnitDbAdapter as a means to suppress certain unit tests on some DBs.
Although looking at this test, I am not quite sure what it tests :) I'd just remove this particular
test actually. 

There are cases when *Cayenne* generates IN clauses, e.g. for prefetching or paginated queries.
And the max size of IN is controlled by the following property:

http://cayenne.apache.org/docs/3.1/api/org/apache/cayenne/configuration/Constants.html#SERVER_MAX_ID_QUALIFIER_SIZE_PROPERTY

But we are not dealing with this here. So yeah, let's remove it.

> Some tests, which tries to delete all records from table where one record has reference
to other record in _the same table_ also ends in error. Usually in method setUpAfterInjection(),
which prepares database to test.
> Firebird doesn't recognise that all records are deleted and denies breaking foreign key
constraint.
> Example of such case is org.apache.cayenne.access.JoinPrefetchTest.
> 
> My question is how to deal with such errors? In this case solution might be removing
references before clearing table, but I'm not sure it is good idea to change code of test
cases.

I am +1 on doing that if it solves the problem. How we prepare test cases is up to us, and
if we come up with a strategy that works with more DBs, I am all for it.

Thanks,
Andrus


Mime
View raw message