Tim,
I've added a few further comments in-lined below.
Shaun
Neil Hauge wrote:
Tim,
Thanks for the detailed comments and questions. Here are some
responses inline...
Tim Wagner wrote:
I worked through a
start-from-RDB case and had some
questions/comments, which I included with my more general questions
below.
- I think the Glassfish
link is wrong; I had to use:
- I couldn’t figure out how
to set the persistence provider, or even what the types of the values
were supposed to be for the two text boxes. Some kind of hint as to
what’s being looked for (directory? jar file? URL? other?) would be
helpful right in the dialog. Better yet would be some kind of
validation/browsing help. Also, could we set a default so I wouldn’t
have to answer the question from scratch the next time?
This is an area that would be simplified by the concept of selecting a
JPA Runtime, which would be extension based. The provider field only
needs to be specified if an application is dependent on a particular
provider. Since we don't yet have the JPA Runtime concept implemented,
we left this as an optionally specified text field to insure that no
one was left out or favored. Unfortunately this does result in a
usability issue.
Shaun: The only reason to select a provider is if you're going to
deploy to a Java EE 5 application server and you don't want to use the
one provided by that server. For example, you're running in JBoss and
want to use TopLink Essentials. You typically won't fill this field
in. The value must be the fully qualified class name of the provider
class--you have to know it. It is possible to make this a class
selection field with completion and a pop up dialog but we'd have to
make it clear that it is an optional field that should only be filled
in for the scenario I described.
- Would it be possible to
include a step-by-step example that includes setting up Derby or some
other O/S DB? If there are issues with being inclusive of vendors, then
I’m happy to have lots of such examples…my concern is just that
struggling to get to the starting point of the Dali demo took me a long
time and a lot of setup steps/patience.
Yes, to get configured for any kind of persistence tutorial takes a lot
of work. We should try to simplify this as much as possible with
canned scripts.
Shaun: Based on comments in the review call I don't see any reason why
we can't provide an example using all open source components for the
demo. We'll get on it.
- What’s the experience
inside WTP? Would we use facets to make this simpler? How else does it
differ from the SE (containerless) case?
Right now the main difference is that for a WTP project we do not have
the user alter the classpath, as we expect the target server in WTP
will have already specified the correct classpath for the project.
Facets and a JPA runtime/library concept would certainly make project
configuration easier. This will be a top priority aftter the 0.5
release.
Shaun: Neil is right, developing JPA applications for deployment inside
a WTP generated EAR is a little simpler. Your Java EE 5 server
classpath should contain all the necessary jars and you don't have to
specify the persistence provider (see previous comment). Right now you
can use WTP to build Java EE 5 applications, you just have to hand edit
the schema and version numbers of the various xml config files like
application.xml and ejb-jar.xml to have them use the EE 5 schemas.
This should disappear when WTP supports generation of EE 5 applications.
- How much annotation
validation exists today? How hard will the migration to APT be? When
will that happen?
There really isn't any annotation validation today in the way you are
thinking of it. All of the current validation is model based
validation, which can apply to annotation or XML based persistence
metadata. In the future we will probably use APT based validation for
specific annotation requirements (duplicate annotations, and other
types of problems that are specific to annotations). So there is no
migration issue, and we will hopefully have some sort of APT support in
before December.
- Build path configuration
in “Add persistence” wizard: Shouldn’t this be a checkbox, on by
default, and then perhaps a button to get to the more complex setup
dialog? Better yet would be offering to add the libraries
automatically…I had to grovel around a little too much to get the
libraries set up, and that felt automatable.
This is where the facet and JPA library type would crtainly simplify
things.
- Heuristic mapping guesses
(substrings, nearest match, etc.)? Any thoughts on a visual surface for
this process? (just curious…obviously not part of this release ;-)
With JPA defaults, the pure matches are done automatically, but ideally
we would also have some sort of automated mapping process that does
exactly what you are suggesting. We have done this work before, so it
is something we would likely move into Dali.
- How hard will DTP
migration be in 3.2?
We are optimistic that this won't be to painful given the similarity
between RDB and DTP, and that we have mostly isolated this dependency
to our db plug-in, so our core model and UI code should not have to
change.
- How much functionality is
covered by your tests? (Same question I had for JSF.)
Probably around 50% at this point. We hope to increase this as we
approach 0.5.
- User docs look pretty
good – need some sections completed, links filled in, and minor
proofreading. I noticed that sections 6.1 and 6.3 seem to be the same
thing. Only major comment is to echo the “getting to the starting point
was a real challenge” issue, and some step-by-step instructions for
various DB providers would have been incredibly helpful. (I used Derby, but it
could have been anything that didn’t require $ to download for
experimentation.)
We will certainly look at how this experience can be improved.
The only other thing I
might add to your slide deck is a brief
(one slide) “development roadmap” to give some guidance on what
features you imagine adding at what pace.
Will do.
Again, apologies for not
having sufficient time in the
schedule today. I’ll respond to Neil’s scheduling email separately.
Neil
--
Shaun Smith
Principal Product Manager
Oracle TopLink
shaun.smith@xxxxxxxxxx
