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 Guys,

  comments inline.

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
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?
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): 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=304881




   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.

-Tom



Best regards
Rainer

---
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
rainer.schweigkoffer@xxxxxxx

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 cooperation.

Back to the top