[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipselink-dev] Updated Proposal for submitted DatabasePlatform integration
- From: "Rainer Kwesi Schweigkoffer" <kwesi@xxxxxxx>
- Date: Wed, 03 Mar 2010 12:41:42 +0100
- Delivered-to: email@example.com
- Organization: SAP AG
- Priority: normal
Hi Tom and Dies,
Tom Ware, am 1 Mar 2010 hast Du um 14:18 zum Thema "Re: [eclipselink-dev] Updated Proposal for submit" geschrieben :
> 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
> If we made that change, we could maintain the JPA SRG as it is and simply
> strongly recommend that platforms run it. Thoughts?
Sounds like a good compromise. One might consider though, whether a DB
platform passing all Core SRG tests without exclusion might be denoted
by something like "qualifies for EL basic usage" and a platform that
passes all JPA SRG tests without exclusion by "qualifies for EL JPA
usage" or something alike.
> 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.
That's a very good suggestion.
> 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.
It will be quite some work to do for sure. However, I'd consider it
already of great value if one decides for a way to go even if it takes
substantial time to reach the end of the road.
> 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.
Actually, the question seems to be whether a bugzilla ticket is
considered to track bugs within EL that need to be solved by the EL
community or whether the perspective is to track and document issues
(and limitations) within and around EL and its usage. Personally I tend
to see the latter view more helpful to EL users. A bugzilla ticket
appears to me a more appropriate way for a comprehensive and flexible
(i.e. up-to-date) description of an issue than its enlistening within
the mentioned wiki page.
Rainer Schweigkoffer SAP AG Walldorf
Business Solution & Technology TD Core JS&I
Technology Development Dietmar-Hopp-Allee 16
Java Server Core D-69190 Walldorf
JEE Implementation Group phone: +49 6227 7 45305
Building 3, G.3.28 fax: +49 6227 7 821177
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Bill McDermott
(Co-CEO), Gerhard Oswald, John Schwarz, Vishal Sikka,
Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your