[ansel] gallery ordering issue

Heath S. Hendrickson heath at outerspaceconsultants.com
Fri Apr 2 09:21:28 PST 2004


Chuck Hagenbuch wrote:

> Quoting Ben Chavet <ben at chavet.net>:
>
>>> Ah, yes, I remember this conversation now. I don't need this to happen,
>>> but one thing you could do is build a
>>
>>
>> build a...?
>
>
> ... psychic connection. Whoops.
>
> You could put "dummy" entries into the datatree for each gallery as 
> images and
> use those as the parents for the image objects, so sort of maintaining 
> a mirror
> tree of the gallery structure.
>
I guess I'm still missing something here...  can someone elaborate on 
how ansel does it currently and what would be different for it to be a 
true parent->child relationship?  I'm failing to see how it would have 
any significant impact on performace, but that's probably because I'm 
not seeing something.

Doesn't every image have a parent that is a gallery already?  If not, 
what is the parent of an image?

Wouldn't it be a trivial matter to set the "type" attribute for all 
galleries so that a listGalleries call would be able to quickly retrieve 
just the galleries (with a simple WHERE clause)? 

On that note, what was the original intent for sub-galleries?  I know 
how I use them (more like a grouping/folder structure to my galleries), 
but I'm assuming that others actually keep images in galleries that then 
have sub-galleries...  Perhaps it might be easier to think of and store 
the gallery as two things... 1) the gallery and it's associated data 
(incl images) and 2) the grouping (which would encompass the nesting 
information).  I know that this would introduce a syncronization issue, 
but isn't that why people use relational databases?  Wouldn't this make 
it much easier to determine the nested structure of galleries?

h



h



More information about the ansel mailing list