Two points, see below
Craig L Russell wrote:
Hi Allen,
On Nov 14, 2006, at 9:06 AM, Allen Gilliland wrote:
Dave wrote:
On 11/13/06, Allen Gilliland <[EMAIL PROTECTED]> 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.
All good.
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.
The hierarchical persistent object and the assoc tables were there for
one purpose: to make it possible to do a recursive query (i.e. query
for all entries under /pets and /pets/dogs, /pets/cats etc.) with only
one SQL statement. But that hasn't worked since we made the switch to
the Hibernate Criteria API back in 2004 and we've been doing fine
without it. And the code that started as complex has been moved around
so much that now it's almost unintelligible.
So I'm +1 with that change.
Actually, I have an idea that I think can accomplish what's described
above and actually kill a couple other birds with the same stone.
Basically, if we add another column for the full path of a node like
you did above (/pets, /pets/dogs, /pets/cats) then to get all entries
under the category /pets by getting all entries that have a category
with a path that starts with "/pets". So the sql query would just be
...
select * from weblogentry,weblogcategory where weblogentry.categoryid
= weblogcategory.id and weblogcategory.path like '/pets%';
Brilliant, never seen this before but it's very clever, and I shall
borrow this.
This would also significantly improve the current performance of the
getPath() methods on our hierarchical objects because it would be a
simple attribute instead of needing to be calculated at runtime. And
this would also be much better for implementing equals() on these
objects since the true key for a hierarchical object is it's path.
The only down side is that the migration path for that would require
walking the category and folder trees for all weblogs and saving the
path for all of them, which is fairly complex :/
It seems to me that this is a tradeoff between simplicity and
performance. Simplicity is storing the local path name and a reference
to the parent; performance is storing the entire path.
Performance seems to be the better tradeoff here. Operations like
moving or renaming a path require recursively changing the entire path
of all children but I assume that the performance benefits outweigh
the complexity of these infrequent operations.
I'm not sure its simplicity; in theory, since the /pets/dogs is the key
to the sub-category, we can only move/update entries and delete
category/sub categories. Its storage vs performance. Storing the
complete path simplifies the SQL, reduces the query resolution time and
potentially eliminates the need to join against the category table.
Craig
-- Allen
- Dave
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!
--
* David Levy *
*Principal Engineer*S
Sun Proprietary & Confidential . This e-mail message is for the sole use
of the intended recipient(s) and may contain confidential and
privilidged information. Any unauthorised review, use, disclosure or
distribution is prohibited. If you are not the intended recepient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
