[ansel] gallery ordering issue

[Heath S. Hendrickson]

Ben Chavet wrote:

>> 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

Are you storing the images in the database as well?  I found that when I 
used MySQL for VFS storage that it was really slow.  When I moved to 
using filesystem storage it got much better...  but then again I'm using 
a PIII 600 w/512MB ram for my server, and it's running a lot of stuff.

I don't know that a rewrite of Ansel is necessary, but you can probably 
tweak the DataTree code to be more specific in it's queries and not 
store so much data when you populate the image classes... maybe we need 
to sub-class some of the Ansel classes so that it's only populating data 
that it needs and not everything under the sun (throw in a 
print_r($image) and see what all is being maintained in memory).  Was 
the overhead associated with parent->child due to intrinsic DataTree 
overhead?  Maybe I'm missing something here, but how much really changed 
between having the relationship and they way it is now?  Is it a flater 
structure now?

Here's what I imagine the structure to be:

       Gallery A (id=0)
          -> image 1
          -> image 2
          -> image 3
          -> Gallery B (id=2)
             -> image 8
             -> image 9
             -> image 10
             -> Gallery F (id=24)
       Gallery C (id=1)
          -> image 4
          -> image 5
          -> Gallery G (id=8)
             -> image 14
             -> image 23
             -> Gallery T (id=78)
                -> image 45
                -> image 54
       Gallery F (id=9)
          -> image 32
          -> image 13
          -> image 56
          -> image 3   (yes, this is an intentional duplicate entry)

I think part of the performance issue might be the fact that the 
database isn't being used in a very relational nature...it's a flat 
structure.  I had been playing around with a design on paper a while 
back that basically had a table for the gallery details (name, 
description, template, etc.), another table for the gallery image lists, 
and a third table for the actual image data (with a possible 4th table 
for the images themselves).  This way you can more efficiently pull the 
data from the database that is needed for a specific purpose (say, 
getting a list of all the galleries for the gallery list) and not have 
to pull all the data at once.

    gallery: gallery_id, gallery_name, gallery_description, 
gallery_comment, gallery_template {key = gallery_id}
    gallery_images: gallery_id, image_id  {key = sequential)
    image_attributes: image_id, image_attr_name, image_attr_value {key = 
sequential}
    image: image_id, image_data {key = image_id}

This way you can have an image in multiple galleries (for example, a 
Picture of the Day gallery and a topic gallery).  It also allows you to 
have dynamic galleries (by searching the image_attributes table for 
specific data, say a date range or a keyword/caption).

I guess my final thought is that it's better to do the redesign now 
while Ansel is still at 0.0.1 (and not listed as being part of the Horde 
3.0 release anyway) than to try and do it once it's considered beta or 
stable...

I know that I'm opening a big can of worms here, but if I just think 
that we should try and make Ansel the best that we can (I'd still like 
the ability to customize the display of each gallery based on a template 
and the ability to have the same image in multiple galleries... but 
those are way down the road).

heath