Okay, I have a little bit more testing that I plan to do, but I think I
am actually very close to having this ready to be committed so I wanted
to give a final heads up and see if there is still anyone who wants to
know more about what I'm changing before I commit. The list of changed
files is here ...
M src/org/apache/roller/pojos/BookmarkData.java
M src/org/apache/roller/pojos/FolderData.java
D src/org/apache/roller/pojos/WeblogCategoryAssoc.java
D src/org/apache/roller/pojos/FolderAssoc.java
M src/org/apache/roller/pojos/WeblogCategoryData.java
D src/org/apache/roller/pojos/Assoc.java
D src/org/apache/roller/pojos/HierarchicalPersistentObject.java
M src/org/apache/roller/pojos/WebsiteData.java
M src/org/apache/roller/business/BookmarkManager.java
M src/org/apache/roller/business/WeblogManager.java
M src/org/apache/roller/business/ThemeManagerImpl.java
A
src/org/apache/roller/business/hibernate/ThreadLocalSessionContextNoAutoClose.java
M
src/org/apache/roller/business/hibernate/HibernateBookmarkManagerImpl.java
M
src/org/apache/roller/business/hibernate/HibernatePersistenceStrategy.java
M
src/org/apache/roller/business/hibernate/HibernateUserManagerImpl.java
M
src/org/apache/roller/business/hibernate/HibernateWeblogManagerImpl.java
M
src/org/apache/roller/ui/authoring/struts/formbeans/WeblogCategoryFormEx.java
M src/org/apache/roller/ui/core/RollerSession.java
M src/org/apache/roller/ui/rendering/plugins/BookmarkPlugin.java
M
src/org/apache/roller/ui/rendering/velocity/deprecated/OldWeblogPageModel.java
most of the changes are in the folders and categories pojos and their
respective manager methods. the rest of the changes are just tweaks
needed as a result of the changes to folders and cats and some cleanup
in the hibernate strategy class.
I am thinking about committing this later this afternoon.
-- Allen
Allen Gilliland wrote:
Anil Gangolli wrote:
+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.
I could do this on the wiki, but it seems easy and short enough to just
do it on the list. So, the most fundamental change is that the
folderassoc and weblogcategoryassoc db tables are not used anymore, and
the HierarchicalPO, Assoc, WeblogCategoryAssoc, and FolderAssoc classes
are all being deleted along with any methods and code which referenced
them.
I'll just detail the weblog category example since it's the same for
folders. So we are going to add a single column 'parentid' to the
weblogcategory table which means the table will look like ...
create table weblogcategory (
id varchar(48) not null primary key,
name varchar(255) not null,
description varchar(255),
websiteid varchar(48) not null,
image varchar(255),
parentid varchar(48)
);
By doing that there are 2 significant changes in the pojo because we can
now directly reference the parent and children of a category using
simple hibernate mappings ...
/**
* @hibernate.many-to-one column="parentid" cascade="none"
not-null="false"
*/
public WeblogCategoryData getParent() {
return this.parentCategory;
}
/**
* @hibernate.set lazy="true" inverse="true" cascade="delete"
* @hibernate.collection-key column="parentid"
* @hibernate.collection-one-to-many
class="org.apache.roller.pojos.WeblogCategoryData"
*/
public Set getWeblogCategories() {
return this.childCategories;
}
So as you can see, the parent of a given category is a simply
many-to-one association and of course for the root node the parent is
NULL. Then for the child nodes it's a typical one-to-many association
which simply points back to the same table and is basically formed by
querying for all categories which list the current object as it's parent.
That basically sums up all the changes as far as associations are
concerned and provides an easy way to walk the tree. The funny thing
was that many of the other methods which I thought would have needed
more tweaking to work with these changes didn't really need much
changing at all. Methods like retrieveEntries() or getPath() were
already being formed by simply walking the tree and compiling the
objects, so they didn't change too much at all.
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.
definitely.
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.
so far I have been able to make all the changes that I think are correct
and I have all the unit tests running correctly, so what I am doing now
is going over the actual webapp and running through all the operations
that I can to find and fix anything that I find. Things are definitely
cropping up, but so far the lazy initialization problem hasn't come up.
The bigger problem has been caused by changing the hibernate config to
use FlushMode.NEVER, which means that hibernate doesn't flush its state
to the db until we explicitly call the flush() method on the Session. As
it turns out, a *lot* of the stuff we were doing has been very reliant
on auto flushing for it to work, so there have been a handful of places
where I have had to figure out how to fix that problem. So far so good
though, and I hope to have things cleaned up enough to commit in the
next day or so.
-- Allen
--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!
