[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipselink-dev] Updated Proposal for submitted DatabasePlatform integration
- From: Tom Ware <tom.ware@xxxxxxxxxx>
- Date: Fri, 05 Mar 2010 16:12:43 -0500
- Delivered-to: email@example.com
- User-agent: Thunderbird 126.96.36.199 (Windows/20090812)
Rainer Kwesi Schweigkoffer wrote:
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
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.
I have updated the doc to say that the Core SRG is required and the JPA SRG is
strongly recommended - with different criteria for how to get tests to pass.
At the moment, the only change I have made related to the "qualifies for EL JPA
usage" suggestion is to add a JPA SRG category to the test list that goes in
the class comment.
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 have added the following to the suggested class header:
Test results: URL of wiki for test 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.
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 have filed the following bug. Please feel free to add comments (and vote for
it if you want):
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.
I have added some comments to the "Functionality Check List" part of the doc.
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