[
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
