Allen Gilliland wrote:
I'll do my best to recap the things that happened in the hackathon a
couple days ago as well as recap how the alternate backend work is
coming along in general. Others can chime in if I miss something or
get something wrong.
Once again it was Anil Gangolli, Allen Gilliland, Mitesh Meswani, and
Craig Russell who met on sept 13th to discuss the datamapper business
object persistence abstraction. This time we had a little less time
to work and spent a fair amount of the time working through some
discussions about the build process and where configs should be and
how to get them there.
We decided that the build process for the business layer needed some
tweaking to better allow Craig and Mitesh to do custom work for
building the datamapper and generating things like jdo mapping files.
Allen agreed to take a look at this.
We also found that there were some complexities with the unit testing
process which were making things slower and harder than was needed, so
Allen and Mitesh were going to work together to try and clean that up
a little bit. The main goals were to make it possible to run the
tests without having to do a full rebuild and recompile and also to
see if there is a way to enable the business layer tests to only
require building of the business layer and its tests.
We also spent a little time talking about requirements for JDO and JPA
and found that JDO should be fine working with Rollers current build
setup, but a JPA implementation may require jdk 1.5. Mitesh agreed to
double check this and report on it for sure.
It is not possible to run a JPA app on 1.4. Even if we compile the POJOs
(the persistent objects) with 1.4 by separating out metadata into an xml
file, the api jars and most of the JPA implementations (glassfish,
hibernate and kodo) are compiled with target=1.5 and hence have
classfile version (49.0) that is not compatible with 1.4
Thanks,
Mitesh
Current status on the work overall:
We all agreed that the datamapper strategy should work and is worth
pursuing, so Craig is continuing down that path and flushing out the
rest of the code for that in the sandbox.
Craig is already onboard and working on a JDO specific implementation
via the datamapper, and Mitesh Meswani also joined the hackathons and
has offered to work on a JPA specific implementation also using the
datamapper. So we should have both a JDO and JPA backend when it's
all said an done.
Now that we've worked through some of the initial design issues and
have fixed up most of the remaining obstacles in the build process we
mostly leaving the rest to Craig and Mitesh to flush out the rest of
the code.
Some of the issues/items that have come up are things that affect the
main src tree of Roller, so I'll talk about how/when we would address
those in another email.
That's pretty much it. I have a few more comments and updates inline
below ...
Craig L Russell wrote:
Anil Gangolli, Allen Gilliland, Mitesh Meswani, and Craig Russell met
yesterday to discuss the datamapper business object persistence
abstraction.
We reviewed and checked in the Datamapper code that Craig put
together. Some updates from the session were also checked in; other
code that was reviewed still needs to be checked in. We checked the
code into the Roller 3.0 branch.
We looked at the DatamapperRollerImpl and refactored it a bit. Most
subclasses of DatamapperRollerImpl would use the Datamapper manager
classes directly so we eliminated the indirection from getXXXManager.
A subclass of DatamapperRollerImpl, e.g. JDORollerImpl, would have to
implement the getXXXManager method and not the createXXXManager.
The current code assumes that a Datamapper transaction is begun the
first time the Strategy is accessed after a transaction is completed
via flush(). This might or might not begin a database transaction
(this is assumed to be figured out by the Strategy implementation).
The flush() method should commit the current work; release() should
roll back any uncommitted work and free all persistence resources.
We agreed that the PersistentObject is probably not the direction we
want to go, but we will need to look at it in detail. The equals
method in PersistentObject is suspect but we don't want to get rid of
it without looking at it a bit more. Methods in Hibernate Strategy
also take Assoc and HierarchicalPersistentObject in addition to
PersistentObject as arguments, and these need to be investigated as
well. These are the types of Bookmark, Category, and Folder (these
are complex aggregate objects that need special treatment for
lifecycle operations).
This item affects Roller in general and is something that should be
looked at in the relatively near future. A couple basic thoughts came
out of this ...
1. pojos shouldn't have to explicitly identify that they are
persistent, that should happen transparently. so eventually we would
like to eliminate the PersistentObject class.
2. the way persistent hierarchical objects work is complex and
confusing. it would be nice to reevaluate this code and see if it can
be simplified and improved.
The DatamapperQuery interface needs to be split into two parts,
because delete only has a small number of methods and it's required
to know up front if a query is going to be used for delete or query.
We decided that we would try to avoid using Update queries (Craig
thinks Update queries are ill-informed and should be avoided). Craig
agreed to update the DatamapperQuery interface and add a new
DatamapperRemoveQuery interface, along with a new newRemoveQuery
method on DatamapperPersistenceStrategy as a factory.
We think that the business objects generally can assume that all
operations use the same thread and the operations can therefore use a
thread-associated DatamapperPersistenceStrategy instance. Allen
agreed to look at some of the more complex operations involving tiles
and verify that the thread association is a good assumption.
I looked into this last week and found that this is indeed the case.
Any request coming into the appserver will remain on the same through
throughout its lifecycle.
-- Allen
Initialization of the environment uses a singleton pattern for
RollerImpl as well as all the XXXManager classes. All of the business
methods of XXXManager are stateless and therefore need to delegate to
a singleton Strategy. RollerImpl itself implemented a singleton
pattern, even though the caller, RollerFactory, itself implements the
singleton pattern. We changed the DatamapperRollerImpl to simple
create an instance each time the instantiate method was called,
simplifying the logic and eliminating the duplicate static instance.
The Strategy instance is also a singleton which allows the
XXXManagers to simply invoke the method, which is responsible for
delegating to the thread-associated implementation object (e.g. JDO
PersistenceManager, JPA EntityManager, or Hibernate Session).
For the most part, the XXXManager classes are responsible for a
single domain object class. Exceptions to this pattern are a few
classes where there is no clear separation, such as Bookmark which
needs to manage the set of classes associated with Bookmarks.
Where an XXXManager class needs to perform work that involves more
than one domain class, it should delegate to another XXXManager to do
the work. The pattern is to get the other XXXManager from the Roller
singleton and delegate. Things like iterating a collection of
instances acquired from another XXXManager should be looked at; it
might be better to delegate to a method in the other XXXManager that
does the iteration as well. Specific example is in
PingTargetManagerImpl:
// Remove the website's auto ping configurations
AutoPingManager autoPingMgr =
RollerFactory.getRoller().getAutopingManager();
List autopings = autoPingMgr.getAutoPingsByTarget(ping);
Iterator it = autopings.iterator();
while(it.hasNext()) {
this.strategy.remove((AutoPingData) it.next());
}
We agreed that this might be better implemented as:
// Remove the website's auto ping configurations
AutoPingManager autoPingMgr =
RollerFactory.getRoller().getAutopingManager();
List autopings = autoPingMgr.removeAutoPingsByTarget(ping);
We agreed to meet again, same time, same place, on September 13.
Craig Russell
[EMAIL PROTECTED] http://db.apache.org/jdo
