[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] JPA support for additional database
|
Hi Dies,
I'll try to address your questions about testing in my response to your
follow-up email. Here's some info about the incubator.
We have been doing some work on our incubator recently and as part of that
work, I have added a placeholder for the SymfowarePlatform. The beginnings of
the documentation are here:
http://wiki.eclipse.org/EclipseLink/Development/Incubator/Extensions/SymfowarePlatform
Theoretically, you should be able to edit that page if you login with your
Eclipse bugzilla id. Let me know if you have problems.
That page includes a pointer into the repository location where we will
initially put your contribution.
Initially the package will be
org.eclipse.persistence.extensions.platform.database. When we move into the
main project we will remove the "extensions" part.
Please feel free to contribute your work at any level of completion you are
comfortable with. We can document the state of completion on the wiki.
-Tom
Dies Koper wrote:
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
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
