Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Updated Proposal for submitted DatabasePlatform integration 
Hi Rainer and Dies,

  I am really hesitant to remove tests from the JPA SRG that exercise
legitimate JPA functionality, simply based on the fact that one database
platform cannot run that test.  When I think of the phrase "JPA Minimum", I
really think of the TCK and passing the TCK is more difficult that passing our
JPA SRG.

  I do, however, think you bring up a good point.  There should be some minimum
set of testing any DatabasePlatform that is available in EclipseLink is capable
of passing.

  JPA is likely one of the more common deployment architectures, but it is
certainly not the only one.  EclipseLink, for instance, provides support for
data sources that abstract legacy database layers.  The goals of users using
that support is often unrelated to the functionality provided by JPA.

  Based on that assumption, I wonder if we should focus on what is required to
have basic Object Relational functionality working on a particular database. In
my opinion, that requires that basic Create, Update and Delete functionality
works for a reasonable set of data-types, rather than whether a particular type
of subselect works that allows us to enable a JPA-mandated feature.

  Should we consider reducing the minimum functionality to simply include the
Core SRG?  When a new database platform is not capable of passing an SRG test,
we could then have the discussion about whether to move the test or disallow the
platform.

  If we made that change, we could maintain the JPA SRG as it is and simply
strongly recommend that platforms run it.  Thoughts?


  As for the testing, the issue I have with listing the failing tests in the
header is that the test results will potentially be different with each version
of EclipseLink.  My suggestion is to have a link to the wiki page with the test
results in the header.  That way users can see the whole history of results.

  I think the idea of a skip annotation is a good one.  At the moment, we only
require JUnit 3 to run the tests and the majority of the tests were written in
JUnit 3.  We would have to do some investigation into whether any work is
required to migrate our tests to accept the annotations and to have the neccesary data available for the annotations. 

  I think adding a bugzilla item for failing SRG tests is a great idea.  I'll
add it to the proposal. I am not sure we have to avoid filing bugs for JDBC driver issues and database limitations. We can always set those bugs as WONTFIX with an explanation. 

-Tom

Dies Koper wrote:

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.


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top