Dave wrote:
We've now got the Roller JPA implementation in the sandbox passing
100% of the JUnit "business" tests and I'm able to run the Roller Web
UI via JPA now.
However, there still couple of issues/problems:
1) Currently, not configured via JNDI datasource but instead by property
file.
2) Need schema change for weblogcategory table to allow websiteid to be
null
and I'm reluctant to put commit this change into the Roller schema as
websiteid
is required for categories.
definitely -1 here. this must be a problem with the implementation, not
the db table.
3) Separation of Planet code in apps/planet makes running Planet tests
against
the JPA backend difficult so I haven't run the PlanetManagerTest yet.
I think the real key here is that the Planet app needs to be handled
separately, and since Weblogger depends on Planet it probably makes
sense to get planet working first. Of course, you can run the Weblogger
code without planet, so I'm not sure how this is really causing problems.
4) The Roller UI comes up but sanity testing revealed these problems:
- Weblog edit: Missing categories in weblog edit page
- Comment mgmt: Marking comment as spam fails
- Categories: remvoing category throws exception
- Planet config: access config page throws exception
Some of these may just be bugs that have been introduced into the trunk
over the past revisions and affect the Hibernate backend as well. Need
more details to look into them though.
5) There are a number of TODO markers in the implementation that concern
me,
especially the ones that say "TODO: handle offset and length".
I'll keep testing and debugging items from #4. As I do that I'll add
new tests because those failures almost certainly indicate that we
don't have good enough test coverage.
To address item #3 I'd like to move the JPA/JDO code from the sandbox
and into the apps/planet/src directories.
Allen has two concerns about that move: 1) putting JPA/JDO
implementation under source will require developers to support two
backends and 2) putting JPA/JDO implementation under source implies
that we support JPA/JDO. To address those concerns, I'll change the
build process so that it specifically excludes the JPA/JDO code --
that way, those not interested in JPA/JDO can ignore the code and
since it's not distributed in Roller -- there's no question that we do
not support it.
Anybody have other objections to moving JPA/JDO code out of the sandbox?
Yes, I know it's a little annoying, but I am against moving that code
into the main src tree. If working out of the sandbox is causing
problems then I think the other option is a branch, but moving the code
into the main src tree, both for Weblogger and Planet does not seem like
the best idea to me.
Granted that there are concerns from a technical point of view around
having to change the build process and making sure that code doesn't go
into normal builds/releases, but to a larger degree I think it's just
not a practice we should endorse. We can't set a precedence of allowing
experimental code to go into the main src tree just to make it easier on
the people working on that code, that's specifically why we have a
sandbox and can provide different branches in the repository.
-- Allen
Craig and Mitesh: Any comments/suggestions on the other items #1, #2 and
#5?
- Dave
