Re: gallery ordering issue
"Heath S. Hendrickson" <[email protected]>
| Newsgroups | gmane.comp.horde.ansel |
|---|---|
| Message-ID | <[email protected]> |
Chuck Hagenbuch wrote: > Quoting Ben Chavet <[email protected]>: > >>> 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 -- ansel mailing list - Join the hunt: http://horde.org/bounties/#ansel Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: [email protected]