You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2007/01/24 17:03:11 UTC
Roller JPA backend status
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.
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.
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
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?
Craig and Mitesh: Any comments/suggestions on the other items #1, #2 and #5?
- Dave
Re: Roller JPA backend status
Posted by Dave <sn...@gmail.com>.
Comments below...
On 1/24/07, Allen Gilliland <al...@sun.com> wrote:
> > 1. Stay the course. JPA continues as a second class citizen, remains in
> > the sandbox, and might not work, subject to feature development in the
> > main line. "Someone" will have to come along after a checkin to make
> > sure that the sandbox code continues to work.
>
> I think this has to be the path until it's been fully decided that JPA
> is going to be a fully supported backend for Roller.
It's time to make that decision.
> > 2. Switch out Hibernate API and use JPA API as the one API that is
> > supported by Roller. Note that since Hibernate has a JPA implementation,
> > current users of Roller could continue to use Hibernate but with a
> > different API.
> >
> > 3. Support both JPA and Hibernate native APIs in Roller. New feature
> > development would have to test in both JPA and Hibernate modes before
> > checking in.
>
> Definitely -10 from me. I am not willing to officially endorse multiple
> backends for the project, no matter how easy it may seem. I think we
> definitely need to pick a single solution to endorse and that's it.
Same here. Been there, done that, burned the t-shirt. I don't want
Roller developers to have to implement every feature in multiple
back-ends.
> I am a little surprised to hear that, but I guess it was
> miscommunication. From the very beginning I think that everyone was in
> agreement that we would only officially support a single backend, so if
> it was going to be something other than the current Hibernate impl then
> that meant replacement
Yeah, I thought that was the consensus too.
> Just because it's working doesn't mean it's time to commit it to the
> main src tree and endorse it. Assuming that the community has properly
> discussed the issue and come to a decision (which hasn't happened yet)
> and assuming all the proper testing and verification has been done
> (which hasn't happened yet) then we can talk about how/when to commit it
> to the main src tree. IMO your suggestion that it's ready to go into
> the main src tree is a bit premature.
I disagree with Allen here. I'm OK with experimental code in trunk and
under src as long as it is clearly marked and does not interfere with
propduction code.
> For one thing, can the JPA backend work on jdk 1.4? I haven't worked
> with any of the JPA stuff myself, but I am assuming that it requires
> Java 5 which means that we would be forcing all Roller users onto a new
> jdk version. So that's an important decision which will affect the timing.
It does work with Java 1.4.2 so that's not a major issue.
> The second part of the timing issue just has to due with stability and
> good practices for releases. IMO swapping out the whole backend on a
> minor release such as 3.1 -> 3.2 is not something that mature products
> do. A change like this warrants a major release, so assuming it is
> ready it should be scheduled for the 4.0 release and not sooner. This
> then suggests that we should take all the current code in the trunk and
> make a 3.2 release out of it, which would still be premature considering
> that 3.1 hasn't even gone out.
Yes, I agree. A new back-end should not be introduced in a point
release. I'm going to propose today a Roller 4.0 release with JPA so
that we can have the discussion and hopefully make a decision.
- Dave
Re: Roller JPA backend status
Posted by Allen Gilliland <al...@sun.com>.
I'll shoot first ...
Craig L Russell wrote:
> Hi Dave,
>
> I'm afraid that we're rolling over a cliff here. I'd like to have a
> discussion and resolution on the future of the JPA sandbox work, and
> IMHO putting it into a branch just defers the real decision that we need
> to make.
I agree that talking about this is good, but I don't think that a branch
is deferring any decisions. That fact remains that big chunks of work
such as this *should* be done in a branch and stabilized there before
moving to the trunk. So regardless of the decision I think that a
branch is the appropriate next step.
>
> There are advantages and disadvantages with using JPA instead of
> Hibernate native APIs, and we need to resolve whether Roller will
> support a single back end or multiple back ends.
>
> I think there are three end results:
>
> 1. Stay the course. JPA continues as a second class citizen, remains in
> the sandbox, and might not work, subject to feature development in the
> main line. "Someone" will have to come along after a checkin to make
> sure that the sandbox code continues to work.
I think this has to be the path until it's been fully decided that JPA
is going to be a fully supported backend for Roller.
>
> 2. Switch out Hibernate API and use JPA API as the one API that is
> supported by Roller. Note that since Hibernate has a JPA implementation,
> current users of Roller could continue to use Hibernate but with a
> different API.
>
> 3. Support both JPA and Hibernate native APIs in Roller. New feature
> development would have to test in both JPA and Hibernate modes before
> checking in.
Definitely -10 from me. I am not willing to officially endorse multiple
backends for the project, no matter how easy it may seem. I think we
definitely need to pick a single solution to endorse and that's it.
>
> When I started working on this project, I anticipated outcome 3. I'm
> used to implementing and using pluggable back ends and this applies
> equally to hardware platforms, Java VMs, persistence APIs, and
> databases. It was a bit of a surprise to me that this was not the
> expectation of the rest of the team, but it was rather late in the cycle
> when I discovered this would be an issue.
I am a little surprised to hear that, but I guess it was
miscommunication. From the very beginning I think that everyone was in
agreement that we would only officially support a single backend, so if
it was going to be something other than the current Hibernate impl then
that meant replacement
>
> I understand that in the early stages of the project, there was some
> skepticism in the team that the JPA API would be suitable for
> production. I would say that we should be past discussion on this point.
> We're down to fine points in the implementation.
Just because it's working doesn't mean it's time to commit it to the
main src tree and endorse it. Assuming that the community has properly
discussed the issue and come to a decision (which hasn't happened yet)
and assuming all the proper testing and verification has been done
(which hasn't happened yet) then we can talk about how/when to commit it
to the main src tree. IMO your suggestion that it's ready to go into
the main src tree is a bit premature.
For one thing, can the JPA backend work on jdk 1.4? I haven't worked
with any of the JPA stuff myself, but I am assuming that it requires
Java 5 which means that we would be forcing all Roller users onto a new
jdk version. So that's an important decision which will affect the timing.
The second part of the timing issue just has to due with stability and
good practices for releases. IMO swapping out the whole backend on a
minor release such as 3.1 -> 3.2 is not something that mature products
do. A change like this warrants a major release, so assuming it is
ready it should be scheduled for the 4.0 release and not sooner. This
then suggests that we should take all the current code in the trunk and
make a 3.2 release out of it, which would still be premature considering
that 3.1 hasn't even gone out.
So all in all, I'm glad this work is coming along, but I don't think
that the project is ready to assimilate it yet. There are a number of
things to consider before just shoving this code into the src tree and I
don't think we've thought through and discussed all of them.
-- Allen
>
> From Allen's and Dave's comments, we are ready to have the discussion
> on the outcome.
>
> Craig
>
> On Jan 24, 2007, at 9:48 AM, Dave wrote:
>
>> On 1/24/07, Allen Gilliland <al...@sun.com> wrote:
>>> > 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.
>>
>> I believe I have sufficiently addressed your specific concerns and I
>> don't have any problem with allowing experimental code under the src
>> directory as long as it is clearly marked and does not affect
>> production code, but...
>>
>> That said, I do not object to doing the remaining JPA work in a branch
>> and it sounds like now might be a good time to create that branch. So,
>> I propose that we create a roller_jpa branch and within that branch
>> move JPA from sandbox to src and apps/planet/src. Once JPA is solid
>> and supportable, we'll merge back. Any objections to that plan?
>>
>> - Dave
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Roller JPA backend status
Posted by Dave <sn...@gmail.com>.
On 1/24/07, Craig L Russell <Cr...@sun.com> wrote:
> I'm afraid that we're rolling over a cliff here. I'd like to have a
> discussion and resolution on the future of the JPA sandbox work, and
> IMHO putting it into a branch just defers the real decision that we
> need to make.
Yes, I agree. We need a proposal for getting JPA into Roller.
> There are advantages and disadvantages with using JPA instead of
> Hibernate native APIs, and we need to resolve whether Roller will
> support a single back end or multiple back ends.
>
> I think there are three end results:
>
> 1. Stay the course. JPA continues as a second class citizen, remains
> in the sandbox, and might not work, subject to feature development in
> the main line. "Someone" will have to come along after a checkin to
> make sure that the sandbox code continues to work.
>
> 2. Switch out Hibernate API and use JPA API as the one API that is
> supported by Roller. Note that since Hibernate has a JPA
> implementation, current users of Roller could continue to use
> Hibernate but with a different API.
>
> 3. Support both JPA and Hibernate native APIs in Roller. New feature
> development would have to test in both JPA and Hibernate modes before
> checking in.
>
> When I started working on this project, I anticipated outcome 3. I'm
> used to implementing and using pluggable back ends and this applies
> equally to hardware platforms, Java VMs, persistence APIs, and
> databases. It was a bit of a surprise to me that this was not the
> expectation of the rest of the team, but it was rather late in the
> cycle when I discovered this would be an issue.
I've had some experience supporting multiple back-end implementations.
It is no fun at all and a distraction from what Roller really needs
which is better UI, easier installation and cool new features.
> I understand that in the early stages of the project, there was some
> skepticism in the team that the JPA API would be suitable for
> production. I would say that we should be past discussion on this
> point. We're down to fine points in the implementation.
Yes. I agree. We need to have that discussion now and I'm going to
kick it off by introducing a proposal for Roller 4.0 with JPA today.
- Dave
Re: Roller JPA backend status
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dave,
I'm afraid that we're rolling over a cliff here. I'd like to have a
discussion and resolution on the future of the JPA sandbox work, and
IMHO putting it into a branch just defers the real decision that we
need to make.
There are advantages and disadvantages with using JPA instead of
Hibernate native APIs, and we need to resolve whether Roller will
support a single back end or multiple back ends.
I think there are three end results:
1. Stay the course. JPA continues as a second class citizen, remains
in the sandbox, and might not work, subject to feature development in
the main line. "Someone" will have to come along after a checkin to
make sure that the sandbox code continues to work.
2. Switch out Hibernate API and use JPA API as the one API that is
supported by Roller. Note that since Hibernate has a JPA
implementation, current users of Roller could continue to use
Hibernate but with a different API.
3. Support both JPA and Hibernate native APIs in Roller. New feature
development would have to test in both JPA and Hibernate modes before
checking in.
When I started working on this project, I anticipated outcome 3. I'm
used to implementing and using pluggable back ends and this applies
equally to hardware platforms, Java VMs, persistence APIs, and
databases. It was a bit of a surprise to me that this was not the
expectation of the rest of the team, but it was rather late in the
cycle when I discovered this would be an issue.
I understand that in the early stages of the project, there was some
skepticism in the team that the JPA API would be suitable for
production. I would say that we should be past discussion on this
point. We're down to fine points in the implementation.
From Allen's and Dave's comments, we are ready to have the
discussion on the outcome.
Craig
On Jan 24, 2007, at 9:48 AM, Dave wrote:
> On 1/24/07, Allen Gilliland <al...@sun.com> wrote:
>> > 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.
>
> I believe I have sufficiently addressed your specific concerns and I
> don't have any problem with allowing experimental code under the src
> directory as long as it is clearly marked and does not affect
> production code, but...
>
> That said, I do not object to doing the remaining JPA work in a branch
> and it sounds like now might be a good time to create that branch. So,
> I propose that we create a roller_jpa branch and within that branch
> move JPA from sandbox to src and apps/planet/src. Once JPA is solid
> and supportable, we'll merge back. Any objections to that plan?
>
> - Dave
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Roller JPA backend status
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 1/24/07, Allen Gilliland <al...@sun.com> wrote:
>> > 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.
>
> I believe I have sufficiently addressed your specific concerns and I
> don't have any problem with allowing experimental code under the src
> directory as long as it is clearly marked and does not affect
> production code, but...
>
> That said, I do not object to doing the remaining JPA work in a branch
> and it sounds like now might be a good time to create that branch. So,
> I propose that we create a roller_jpa branch and within that branch
> move JPA from sandbox to src and apps/planet/src. Once JPA is solid
> and supportable, we'll merge back. Any objections to that plan?
nope. that sounds like a good plan to me.
-- Allen
>
> - Dave
Re: Roller JPA backend status
Posted by Dave <sn...@gmail.com>.
On 1/24/07, Allen Gilliland <al...@sun.com> wrote:
> > 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.
I believe I have sufficiently addressed your specific concerns and I
don't have any problem with allowing experimental code under the src
directory as long as it is clearly marked and does not affect
production code, but...
That said, I do not object to doing the remaining JPA work in a branch
and it sounds like now might be a good time to create that branch. So,
I propose that we create a roller_jpa branch and within that branch
move JPA from sandbox to src and apps/planet/src. Once JPA is solid
and supportable, we'll merge back. Any objections to that plan?
- Dave
Re: Roller JPA backend status
Posted by Allen Gilliland <al...@sun.com>.
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
Re: Roller JPA backend status
Posted by Allen Gilliland <al...@sun.com>.
Mitesh Meswani wrote:
> Dave wrote:
>>
>> 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.
> There is a circular dependency between WebsiteData and WeblogCategoryData.
> This is due to following ManyToOne relationships
> Class WebsiteData {
> ....
> @ManyToOne WeblogCategoryData bloggerCategory
> @ManyToOne WeblogCategoryData defaultCategory
> ....
> }
>
> Class WeblogCategoryData {
> ....
> @ManyToOne WebsiteData website
> ....
> }
>
> Toplink puts WeblogCategoryData above WebsiteData in commit order hence
> a shallow insert (that is website set as null at insert and updated
> after insert of corresponding WebsiteData) is performed while inserting
> an instance of WeblogCategoryData. This requires to change the table
> definition for weblogcategory be changed to have column websiteid as
> nullable. I have not yet gone through hibernate code to see how it
> handles the situation but I think many other providers also might run
> into the same issue as toplink.
This is a problem in Toplink or the JPA impl, not a problem with the
database table definition. Every category *must* be attached to a
weblog. If you look at the WebsiteData pojo you will also notice that
both of the category associations you mentioned are listed as nullable,
so you can insert a website with null default and blogger categories,
then create those categories, assign them to the website, and save them.
-- Allen
Re: Roller JPA backend status
Posted by Mitesh Meswani <Mi...@Sun.COM>.
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.
I think this is doable. Can you please give some more details on what is
the expectation?
>
> 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.
There is a circular dependency between WebsiteData and WeblogCategoryData.
This is due to following ManyToOne relationships
Class WebsiteData {
....
@ManyToOne WeblogCategoryData bloggerCategory
@ManyToOne WeblogCategoryData defaultCategory
....
}
Class WeblogCategoryData {
....
@ManyToOne WebsiteData website
....
}
Toplink puts WeblogCategoryData above WebsiteData in commit order hence
a shallow insert (that is website set as null at insert and updated
after insert of corresponding WebsiteData) is performed while inserting
an instance of WeblogCategoryData. This requires to change the table
definition for weblogcategory be changed to have column websiteid as
nullable. I have not yet gone through hibernate code to see how it
handles the situation but I think many other providers also might run
into the same issue as toplink.
>
> 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.
>
> 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
>
> 5) There are a number of TODO markers in the implementation that
> concern me,
> especially the ones that say "TODO: handle offset and length".
This particular comments must be coming from
DatamapperPlanetManagerImpl. As we discussed, we had stopped maintaining
it couple of weeks back. It should be easy to implement the TODOs. There
should be couple of more TODO items in Datamapper*Impl classes. They are
marked as "//TODO: DatamapperPort". Some of them are observations that
I made about improving the code while porting. I needed input from one
of you on whether the optimization makes sense for roller. We will need
to go over them individually.
Regards,
Mitesh
> 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?
>
> Craig and Mitesh: Any comments/suggestions on the other items #1, #2
> and #5?
>
> - Dave
Re: Roller JPA backend status
Posted by Anil Gangolli <an...@busybuddha.org>.
No objections, but some confusion on my part as to the plan moving forward.
What happened to the suggestion to do the work on a dev branch? Wouldn't
that address this as well? It seems like we are seeing yet another instance
of sandbox not being as flexible as branch.
--a.
----- Original Message -----
From: "Dave" <sn...@gmail.com>
To: <ro...@incubator.apache.org>
Cc: <Mi...@Sun.COM>; <Cr...@Sun.COM>
Sent: Wednesday, January 24, 2007 8:03 AM
Subject: Roller JPA backend status
> 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.
>
> 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.
>
> 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
>
> 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?
>
> Craig and Mitesh: Any comments/suggestions on the other items #1, #2 and
> #5?
>
> - Dave
>