hi,

can someone quickly explain the nature of the parentid in the album table ?
I either miss a link or the last upgrade has fiddled with it.
I would have thought that the parent id is always the next album level up.

Please see my dump below.
Why does 'Boquete' have a parent id of a dynamic album ?
That seems wrong to me. I think it should link to 155.

If that is correct than the upgrade from RC to 1.2.8 must have done that I haven't touched this table manually. Should I correct this ?
Not sure this is really a bug because in the admin section the hierarchy looks correct.
i.e. 'Boquete' is shown under '2008' as I want it.
I discovered this working on a custom SQL...

What is going on here ? Shouldnt 'Boquete' have parentid = 155 ???

id --- parentid --- folder --- name
17 --- NULL --- rooms --- rooms
155 --- 17 --- rooms/2008 --- 2008
269 --- 276 --- rooms/2008/Boquete --- Boquete
276 --- 17 --- rooms/Cheap_Hotels.alb --- Cheap_Hotels

There is a bug in setup caused by having a dynamic album containing albums. Setup is checking for valid parent ids (the database ID of the parent album) and correcting them when it finds an error. Unfortunately it should not be checking dynamic album s ubalbums for parent ids since they really do not "own" any albums.

This is corrected in the nightly builds. But for now, if you re-run setup it should re-fix the parent id.

as usual, great help. Thanks !
How come the hierarchy is maintained in the admin & viewer then ?
Is it derived from the folder tree not the parent id ?
If yes that is a good approach !
Too often I have seen poorly replicated a filesystem hierarchies
instead of just using the file system

The arbitrator is the file system. However, the database is used in things like move/copy and associating albums to tags, etc.

hmmm I just have rerun the setup and the parentid got twisted again.
So upgrading to the nightly build will fix this ?
I rather avoid this, any alternative ?

I did upgrade to nighty build and its all happy now
well other than that the
function printSortableAlbumLink($text, $title, $class=NULL, $id=NULL)

seemingly did get abandoned, but that is fine with me

Cheers

P.S. : also the distorted landscape thumbs from portrait images are gone and the law of the thirds looks loads better !

We re-did tha image/album sorting so it would work with jQuery 1.4, etc. The old class-sortables was the problem with the incompatiblilties so it went away, along with the printSortableAlbumLink() function. That seemed only to be used in the admin toolbox function and seemed really overkill since all the link really is was a link to admin-albumsort.