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

["Rainer Kwesi Schweigkoffer" <kwesi@xxxxxxx>]

Tom Ware, am 23 Feb 2010 hast Du um 9:25 zum Thema "Re: [eclipselink-dev] Updated Proposal for submit"  geschrieben :

>    At the moment, I think of the SRG tests as a test set that exercises the 
> fundamental parts of EclipseLink. The core SRG exercises the basic CRUD 
> functionality for a reasonably large set of data-types.  The JPA SRG exercises 
> the basic JPA operations.  In general, I think that we expect our platforms to 
> pass these tests.  There are, however some exceptions.
> 
>    Lets take the example of the Symfoware platform that is currently being 
> developed.  There are issues with running Update and Delete JPQL queries that 
> reference classes that have multiple tables because neither of the two current 
> implementations in EclipseLink can be supported on Symfoware.
> 
>    In my opinion, it is important to know that this fundamental part of JPA is 
> not working prior and to document that limitation prior to shipping the 
> platform, but I do not want to avoid shipping the SymfowarePlatform based on 
> that limitation.
> 
>    As a result, my first instict is to keep those tests in the SRG so that any 
> platform that ships with EclipseLink either passes those tests, or documents 
> that it does not.  I am, however, open to other suggestions about how we achieve 
> that.
> 
>    I agree that what our SRG test suites contain should be flexible and the fact 
> that a Platform cannot pass a test in the SRG, should bring up a discussion 
> about whether the test belongs in the SRG.

Well, Tom, I have been pondering about this for quite a while now, but 
it still feels to me a bit like somewhat trying to avoid a decision. 
Nonetheless, there is certain value I see in quickly and easily 
understanding what and which EL functionality is available to 
applications independently from the underlying db platform since JPA, 
among others, is used as a database abstraction layer. And I would 
appreciate if a test suite or a set of test suites reflected that 
functionality.

Should we make transparent the feelings you describe above by having 
three layers of tests like

JPA_MIN

tests that run on all db platforms reflecting something like
"EL basic functionality runs with limitations"

JPA_SRG

"EL basic funtionality"

JPA_LRG

"full functionality of EL"

or do you consider that overkill ?

My understanding of the current state of the proposal is that, for a 
new db platform, the difference between not passing an SRG test and not 
passing an LRG test is that the latter is simply documented while the 
the former additionally needs to be dicussed and approved (i.e. not 
objected) on the dev list. If I have gotten that one right, in the 
threefold model it would translate to a failure on either SRG or LRG to 
be simply documented, while a failure on MIN would have to be discussed 
on the list. Approving the failure would then result in the test to be 
moved from MIN to SRG and the db platform to be accepted, while 
objection would make the test stay in MIN and the db platform to 
further be kept in incubation.


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.


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.