Re: Mini-hackathon Sept 13 2006 ( was Re: Mini-hackathon Sept 5 2006)

> 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.

>
> 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
>> clr@... http://db.apache.org/jdo
>>
>>