[ansel] gallery ordering issue

Ben Chavet ben at chavet.net
Thu Apr 1 10:55:33 PST 2004


> Also, what was the reason that there isn't a try parent->child
> relationship for Ansel (I thought that there was, but I haven't studied
> it that closely).  I don't see why it would be that difficult to do, you
> just need to flag what children are sub-galleries and which are images
> (i.e., using the existing "type" attribute).  Then you could just set up
> DataTree with a new function to query for certain object-types under a
> certain parent to get a listing of all sub-galleries and then another
> query to get all images.   This way you can keep the Ansel code a little
> more standard and you don't have lots of workarounds in the code (and it
> makes it easier to update DataTree if you don't have to keep in mind the
> customizations of Ansel).

I did it this way for performance reasons.  It would definitely be 
easier to do
a parent-child relationship, but getting a list of galleries that way takes a
huge performance hit.  This is especially true when you start to get a lot of
images.

For some perspective, while I was writing the current ansel backend 
using my P4
1.8GHz machine, it took about 30 seconds to render my gallery list (65
galleries, 2300 images) with a parent->child relationship between 
galleries and
images.  So, I had to do *something*.  The solution I came up with (abandoning
the parent-child relationship) dropped that render time to about 5 seconds.

I'd still like to see better performance, and I have also considered 
the option
of breaking ansel away from the horde_datatree table.  Even if it were to use
something like ansel_datatree and ansel_datatree_attributes.  My photo 
album is
only going to get bigger & I'm not looking to upgrade my server hardware
anytime soon (dual PIII 800MHz).  So, anything we can come up with for
performance improvement is welcome by me.

Before I started working on ansel, I had my own home-brew photo album 
that used
3 tables.  One for gallery info, such as owner, name, id, etc.  One for image
info, such as owner, id, gallery, etc.  And the 3rd for image binary data.  It
was not nearly as robust or as flexible as ansel, which is why I abandoned it,
but it was much more responsive when getting the gallery lists and photos in
the galleries.

I'm not looking to change ansel's structure, especially as we are 
getting close
to a horde release.  Maybe the performance I am looking for is hiding in the
datatree classes somewhere.

--Ben


More information about the ansel mailing list