[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