[ansel] gallery ordering issue

[Heath S. Hendrickson]

Chuck Hagenbuch wrote:

> Quoting "Heath S. Hendrickson" <heath at outerspaceconsultants.com>:
>
>> I think I'm starting to understand this now... so apparently there is
>> some extra overhead when you assign a datatree_parents value to a record
>> in the datatree...
>
>
> No.
>
Well, apparently there is... because if you look at the code in 
DataTree/sql.php, the _loadByIds() function does an iterative retrieval 
of all parents of an object.  So, if an object has no parent's it will 
load and process faster than an object that has parents, even if you 
don't care about the parents of an object...

>> Out of curiosity, what would it take to add to/modify the behaviour of
>> the DataTree driver to have different ways of accessing the data
>
>
> getByAttributes() is all you could ever want. If it isn't, you 
> shouldn't be
> using DataTree. We're NOT going to rewrite database engines here.
>
I'm not suggesting a complete rewrite, just that there might be ways of 
improving on the code... unless you are going on record as saying that 
DataTree is perfect as it is... (and in that case, why is it still only 
flagged as version 0.0.1...?).

>> Or put another way, does anyone know where the slowdown is coming 
>> from specifically in order to look at it closer and maybe fix it?
>
>
> *What* slowdown?
>
Quoting Ben (from a reply to an earlier question I had about the Ansel 
code, on 4/1/04)::

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.


<end quote>

So obviously there has to be *some* slowdown in using the true 
parent->child relationship of DataTree for Ansel...

So, if the answer is obvious and staring us in the face (like an 
undocumented call or something), please enlighten us all so that we can 
put this to bed once and for all...

After looking through the code a little, here's what I've deduced about 
how it functions (please, correct me if I have something wrong or missed 
something, partly this is to document it all works for amyone else out 
there):

1) user requests Ansel page which in turn calls &getGalleryById($cid)  
[where $cid presumably = -1 for the top-level view]
2) getGalleryById() calls _datatree->getObjectById()
3) _datatree->getObjectById() calls getName() in order to call getObject()
    3a) getName() calls _loadById() if the object isn't already loaded 
in the nameMap
    3b) _loadById() will attempt to load the indicated object and all of 
it's parents (if there are any)
    3c) getName() returns the name associated with the $cid from 1).
4) getObject() then proceeds to call getId() in order to call 
getAttributes() or getData()
    4a) getId() looks up the id from the _nameMap which was created in 3b)
5) getAttributes() or getData() actually do the SQL retrieval of the data...


What's the difference between the $cid and the return of getId()?  If 
they are the same value, then what is the purpose of calling getName() 
only to have to convert it back to an an id later via getId()... (the 
only reason that's apparent to me is to populate the nameMap and load 
the entire tree).

thanks,
h