|
»
»
»
« Return to Thread: Mini-hackathon Sept 5 2006
Mini-hackathon Sept 13 2006 ( was Re: Mini-hackathon Sept 5 2006)
by Allen Gilliland-3
::
Rate this Message:
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
>
>
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
>
>
« Return to Thread: Mini-hackathon Sept 5 2006
| Free embeddable forum powered by Nabble | Forum Help |
