+1 on the cleanup work in general. A big hoorah for the hierarchical object
cleanup!
I'd like to review the changes related to the persistence pattern so that I
understand them, but you can just let me know the commit revisions involved.
If we make these changes, it's good to do it early in the release cycle (as
soon as 3.1 is branched off of main) so they get some road time in
development before we release.
It's not unlikely that we will break some things temporarily and not notice
it for a while. The riskiest aspect to me in this regard is lazy fetching
because it really demands that the session span the entire request, which we
seemed to have a hard time doing properly earlier, and I'm not sure exactly
why. We backed out of lazy fetching just before one release a ways back
because we would hit odd session closed exceptions that we didn't have time
to figure out. It's possible that some of Allen's earlier session
management cleanups already got us out of those issues. It's a good idea to
revisit this now. I think that is also likely to make us more portable to
optimizations in other persistence implementations that expect essentially
the same session management pattern.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, November 13, 2006 4:46 PM
Subject: Re: Business layer cleanup for 3.2
certainly. I didn't do much in the way of renaming things yet, the first
pass was mainly about fixing up the Hibernate config to work the way I
think it should have been working and clearing out some things along the
way. Once that is done then I plan to go over the business layer more
times and find places where methods should be renamed, removed, or
consolidated in any way. I also want to keep building on the unit tests
because I think they are pretty good now, but there are a few gaps here
and there.
At the end of the day this work will definitely help to make the work on
the JDO/JPA backends quite a bit easier.
-- Allen
Craig L Russell wrote:
Hi Allen,
We had discussed a number of issues with the manager classes such as
misspelled method names and incomplete functionality (having the caller
iterate through collections).
I'd be happy to review what you've done in terms of cleanup.
Regards,
Craig
On Nov 13, 2006, at 2:10 PM, Allen Gilliland wrote:
One of the things that I am planning to do for the 3.2 release is do
some audit/cleanup of the current business layer code. There are a
variety of things which could use improving, but the main goal is to fix
our Hibernate configuration so that we are 1) properly using the open
session in view pattern and 2) enabling lazy fetching on all objects and
associations.
Right now our Hibernate config is pretty messy and doesn't take
advantage of many of Hibernate's performance features, so the main
reason to do this work is to improve the performance of the business
layer. The second big reason is just to reduce clutter and simplify the
code as much as possible. There are plenty of places in the code where
we have methods that aren't used at all or methods which are duplicated,
so those would all be cleaned up.
I have most of this work done already (but not checked in) and there
aren't really any surprise changes that I had to make except when it
came to the hierarchical objects. I tried for multiple days to get the
hierarchical objects to work with the updated hibernate config and the
current data model, but I kept running into problems. So to fix the
problem I had to make a small tweak to the way hierarchical objects are
persisted which fixed my issues and I believe drastically simplifies the
problem overall. The basic change is that I have completely removed the
HierarchicalPersistentObject class and Assoc and it's subclasses and
changed the data model so that we have a more normal hierarchical model.
So, for weblog categories I added a simple 'parentid' column to the
weblogcategory table and that allows a category to manage relationships
between it's parent and children directly. Same goes for the FolderData
class, but as it turns out that column already existed in the schema but
wasn't being used. Upgrade path for both of these is fairly simple and
only requires populating these columns with the right value.
I'm not sure if anyone really wants to see more of a proposal for this,
which is why I started with an adhoc description here on the list. As I
said, I am not actually modifying anything from a feature point of view,
only cleaning up what is already there. If anyone wants to see more
about the changes to the hierarchical objects then I can post them on
the wiki or something.
-- Allen
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
