Re: [eclipselink-dev] Updated Proposal for submitted DatabasePlatform in

[Dies Koper <diesk@xxxxxxxxxxxxxxxxxxx>]

Hi Rainer,

I agree with the below.
I have done this as follows:

    public void testTwoUnrelatedResultWithOneToManyJoins() {
        if (getServerSession().getPlatform().isSymfoware()) {
            getServerSession().logMessage("Test
testTwoUnrelatedResultWithOneToManyJoins skipped for this platform, "
                    + "Symfoware doesn't support UpdateAll/DeleteAll on
multi-table objects (see rfe 298193).");
            return;
        }
[...]

But I suppose the creation of bugs is not useful in some cases:

- JDBC driver bug: the bug report should be with the JDBC provider, but
their tracking system might not be public, or they might not even
accept/consider bug reports from non-paying customers.

- Database limitation: The DB doesn't support the EclipseLink/JPA
function, for example the VARIANCE function, so we'll never be able to
fix and close the bug on EclipseLink's side.

So in those cases I've listed the restriction on the EclipseLink
SymfowarePlatform wiki page.

It might be useful to have this for the other (even existing) database
platforms.

I don't see why we should make a distinction for SRG and LRG tests here,
if either has been run and a failure has been investigated, we should
raise a bug (except for the cases I mentioned above of course).

What do you think?

Regards,
Dies


> By the way, independently from the outcome of the above question, I
> would find it quite helpful if the expected failures of tests were not
> only documented in the header of the respective db platform source
> file, but the tests themselves could also be annotated with a skip
> annotation enlistening the db platforms the respective test should not
> be run on - similar to the technique used in the wdf test suite.
> 
> 
> Finally one might want to discuss whether the failure of at least an
> SRG test should yield a bugzilla ticket describing the issue(s)
> encountered, the resulting limitations and available work arounds. The
> ticket number could potentially be referenced by the skip annotation as
> well.