Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] JPA support for additional database

Hi Tom,

I'd like to confirm what actions I can take already and what still needs to be discussed.

> 1. The initial implementation is put in our incubation component.

I'll put my SymfowarePlatform.java in a directory structure as explained on the Incubation wiki. I suppose it will look like:

foundation/trunk/org.eclipse.persistence.core/src/org/eclipse/persistence/platform/database/SymfowarePlatform.java
(with build scripts in org.eclipse.persistence.core/)

Once I've done a bit more testing, I'll create a bug similar to the three bugs listed in your umbrella bug and attach my contribution.

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

From my testing I'll collect information for the documentation on the wiki. Which wiki page can I use for reference? I suppose we need some info to get a user going (example persistence.xml with a jdbc url), known limitations and explanations of what tests were done.

You will review everything and commit the code to the incubator project.

> 2. We decide which tests need to pass and agree on how to run those
> tests and publish the results.  Ideally this includes a strategy to do
> regression testing for each release.

I'm currently trying to run the unit tests in /eclipselink.core.test on Symfoware. I do not know how much of functionality that covers, but they'll give results we can publish.

I assume the final steps in the lifecycle (reviewing/completing documentation and moving SymfowarePlatform into the eclipselink.jar) will go smoothly once the issues in 1. and 2. have been resolved.

In response to other things you said:

> This process is one that is fairly new to us.  As a result, if you or
> any other community members have suggestions, it would be nice to hear
> them so we can develop a process that works for the whole community.

When I first e-mailed you I had not read the Incubation wiki page.
Obviously you have already had some discussions (although I found few updates after Nov/Dec last year, what happened?) so I'd like to make a start with what you have written up first. We can improve the process if required as we go through it.

> For the object relational part of our product there are currently 2 test
> suites we run to test our core functionality in addition to
> standards-based tests like the CTS.
>
> 1. A JUnit-based JPA test suite
> 2. A legacy test suite for our core mapping library

I found the JUnit tests in /eclipselink.core.test. I assume I can ignore the ones in /eclipselink.extension.oracle.test. Is "jsp/eclipselink.jpa.test" also relevant? Are there any other JUnit tests relevant apart from these? Would any tests in the core mapping library legacy test suite be relevant for testing the Symfoware platform?

As I mentioned I have made a start running the /eclipselink.core.test JUnit tests on Symfoware. At the moment, most of them fail. I'll write a separate e-mail about some of the issues I've encountered.

Thanks,
Dies


Tom Ware wrote:
Hi Dies,

  Answers inline:

Dies Koper wrote:
Hi Tom,

Thank you for your quick reply!

You mentioned two conditions for moving a Symfoware platform implementation from the incubation component to the full product.

1. enough community acceptance
2. testing

How do you measure the former?
As Symfoware is mainly used in Japan, and my experience with my Japanese
colleagues at least is that more than a few are not comfortable actively participating in English-language forums, I expect few or no users coming to these forums with questions or telling us their experiences.

In case where we are not likely to get much community feedback we would have to figure out a testing strategy that allows the contributer to provide testing and feed results back to the rest of the community. This is certainly something we can figure out.

We would also want to be sure there was a good way to provide support for the people in the community who use the new platform. (through our mailing lists and forums)


About the latter, what kind of testing would you consider sufficient for inclusion in the full product?

What we intend to do is:
- run CTS's ejb30 tests with Symfoware as the DB.
- run a few standalone Java SE test applications that use JPA.

You mentioned that you don't have a database conformance suite. Do you have any tests that you would like me to run in addition to the above, or any particular functions you think we should focus additional testing on?

For the object relational part of our product there are currently 2 test suites we run to test our core functionality in addition to standards-based tests like the CTS.

1. A JUnit-based JPA test suite
2. A legacy test suite for our core mapping library

Those tests test not-only basic functionality, but parts of EclipseLink that can only work on certain databases due to the features they provide.

To include SymfowarePlatform as part of eclipselink.jar we would want to decide on a subset of those tests that should run successfully. That is also how we would derive our database conformance suite.

In the past, that is the area where some help will be required from the EclipseLink team. We do our best to help anyone who wants to make contributions to EclipseLink, but sometimes some patience is necessary in that area.

Or would you like me to try to make a Symfoware DB installation available to you for testing?

That is an interesting possibility. When we get closer to having a working implementation, I'll discuss this with our QA team what it would take to get Symfoware added to our automated certification test suites.

I am particular interested in having JPA 1.0 functionality working correctly on Symfoware. Once I have access to Java EE 6's CTS, I would like to test its compliance to JPA 2.0 (although we'll include mappings for CASE, NULLIF and COALESCE from the start).

At the moment, our test framework is missing a database conformance suite and this is something that would make your contribution easier. Without that suite, we will do our best to help you with your implementation, but you will likely need to be patient with us.

We have the resources and experience available to provide a proper platform implementation class. We won't need much help with the implementation, but we will need your support (review and acceptance) for it.

We have an incubation component, and the plan is to include new database platforms in that component so they can be distributed and used by the community. This will be especially important for databases such

Do you have to distribute the new platforms separately?
As all are mapped from a regex run against the DB driver metadata, they won't clash with or affect the matured platforms. Your homepage explains which you officially support, so there is no confusion about which you consider "ready for production" either.

Three advantages of not separating them that I can think of are:
1. No extra steps for the users to find and install the extra component.
2. No need to more cleanly extract the database platform specific code (now in TargetDatabase.java, DatasourcePlatform.java, Platform.java, PropertiesHandler.java). Of course it would be nice to clean this up some day, but don't let that hold up our contributions. 3. When a platform implementor wants to make a change to for example a common class like Platform.java, (s)he will easily see the impact on the new platforms too, and can easily update them accordingly.

I think it would help adoption if it is in there by default.

The barrier to including a new platform in the eclipselink.jar is testing and support. That is the reason we hope to resolve community acceptance and testing issues prior to including a new platform in our main product. The goal of anything that appears in our incubation component is to have it make its way into the main product. Here is how I see the life cycle:

1. The initial implementation is put in our incubation component.
  - This includes SymfowarePlatform.java and any support classes
- Any changes to core classes are reviewed and checked into the main product - The incubation component includes a build script and builds a separate jar - Documentation of the component and how to use it is provided on our wiki page - This can occur as soon as we have code (i.e. as long as we document the current state, we can check this in before we pass all the tests)

2. We decide which tests need to pass and agree on how to run those tests and publish the results. Ideally this includes a strategy to do regression testing for each release.

3. When we are happy with testing results we ensure the final SymfowarePlatform is properly documented including documenting how it is tested and any limitations on the implementation and the tests.

4. We move SymfowarePlatform into the eclipselink.jar

This process is one that is fairly new to us. As a result, if you or any other community members have suggestions, it would be nice to hear them so we can develop a process that works for the whole community.

There is interest from other community members in providing support for some other databases in the near future, so hopefully it is an ideal time to have this kind of a discussion.

-Tom



Thanks,
Dies Koper
Fujitsu


Tom Ware wrote:
 > Hi Dies,
 >
 >   The short answer is, yes, we are quite interested in other database
 > platforms.
 >
> In the interest of full-disclosure, the longer answer is that we still
 > need to do a bit of work to make it easy to make that kind of a
 > contribution.
 >
 >   At the moment, our test framework is missing a database conformance
 > suite and this is something that would make your contribution easier.
 > Without that suite, we will do our best to help you with your
 > implementation, but you will likely need to be patient with us.
 >
 >   We have an incubation component, and the plan is to include new
> database platforms in that component so they can be distributed and used > by the community. This will be especially important for databases such
 > as Symfoware where we do not have the ability to test them.  Any new
> database platform will be distributed through that component until they
 > get enough community acceptance and testing to be moved to the full
 > product.
 >
> In fact, there has been some interest lately in providing a number of
 > other database platforms.  This should provide us with the motivation
> necessary to get the incubation component properly set-up. Hopefully we > will also find time to create a database conformance test suite - though > I would be surprised if that happened before our 2.0 release and JPA 2.0.
 >
 > -Tom
 >
 > Dies Koper wrote:
 >> Hi,
 >>
>> EclipseLink's JPA currently has implementations for almost 20 database
 >> platforms.
>> We would like to use EclipseLink's JPA with Symfoware Server, which is
 >> Fujitsu's RDBMS.
 >> http://www.fujitsu.com/global/services/software/symfoware/
 >>
>> I would like to create a patch to add Symfoware support to EclipseLink. >> I think Symfoware is not a famous DB outside of Japan, and as it's not >> OSS, few of you might have heard of it. It has been around for quite a >> number of years (I believe V10 is coming out this year), and we have a
 >> number of customers in Japan using it.
 >>
 >> Would you consider reviewing and incorporating a patch for Symfoware
 >> support?
 >>
 >> Thanks,
 >> Dies Koper
 >> Fujitsu




Back to the top