[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-dev] JPA support for additional database
|
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
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev