0000937: Image level not used in thumbmail associated category

(0003765)
plg (manager)
2010.04.14 17:51

That's OK to hide img1 only if img1 was not explicitely chosen as category representative photo => the category must have a random representative photo.

(0003834)
plg (manager)
2010.05.04 21:07

In fact, it works fine if you have $conf['allow_random_representative'] = true;
and not fixed a representative photo for a given category. But this is a very uncommon situation, simpy because by default $conf['allow_random_representative'] = false; (to reduce CPU load).

I investigate on what can be done (without too many damages on CPU load) when the representative photo is defined. The problem is that it can be defined by user explicitely or automatically when adding photos.

To avoid high CPU load (many queries), it would be better to have {category_id, privacy_level, representative_picture_id} and the corresponding user interface, but it's quite a huge job and certainly confusing for the vast majority of users.

(0003835)
plg (manager)
2010.05.04 22:19

Another solution is to add a column "representative_picture_id" in the user_cache_categories table and fill it only when needed, so that for a given category and a given user the representative photo must be found only once (as long as there is no user cache reset).

Adding this for Piwigo 2.1 is a bit too late, unfortunately :-/ 2.1.0RC3 is already available, and we're not supposed to modify the data model. And without modifying the data model, I don't know how to solve this problem efficiently.

I have to postpone to Piwigo 2.2 :-/

(0004678)
svn (reporter)
2011.01.20 14:32

[Subversion] r8802 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
bug 937 fixed: makes sure a user won't see the thumbnail of a photo that has a
higher privacy level than user privacy level.

For an acceptable solution at performance level, I have implemented a cache:
for a given user, each album has a representative_picture_id. This cache also
avoids to perform numerous "order by rand()" SQL queries which is the case
when $conf['allow_random_representative'] = true;

(0004681)
rvelices (developer)
2011.01.20 16:28

I have an issue with this commit for my config:
- $conf[allow_random_representative']=false
- some specific categories do not have representant because I want to search a representant of sub categories.

Now with this change, you will save once an id in user_repres* and that's it.

(0004682)
plg (manager)
2011.01.20 17:12

> Now with this change, you will save once an id in user_repres*
> and that's it.

Yes I know, this is the expected behavior. We lose a bit of randomness but it avoids numerous and heavy SQL requests.

Do you suggest another way to solve this problem?

(0004683)
plg (manager)
2011.01.20 17:21

We could not use the cache at all, but it is a nightmare at performance level in my opinion.

We could only store the user_repres* if the found repres* level is higher than user.level but if the user is in this situation once, he loses the randomness for futur page refresh.

(0004684)
plg (manager)
2011.01.20 21:13
edited on: 2011.01.20 21:19

I propose to keep this bug fixed (the bug itself is fixed) so that it appears as fixed for 2.2.0RC1. Please open a forum topic to discuss about the problem of the cache and the loss of randomness, we can change the algorithm for 2.2.0RC2 if we find a better solution.

(0004685)
rvelices (developer)
2011.01.20 21:33

ok. let me see how i feel a week from now... maybe i'll love it

(0004686)
plg (manager)
2011.01.20 21:35

You'll love the speed if you $conf['show_gt'] = true + $conf['show_queries'] = true

But I agree that randomness was pleasant.

(0004845)
svn (reporter)
2011.02.24 12:30

[Subversion] r9365 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
bug 937: problem on empty albums (visible for admins) with a representative_picture_id defined.

Issue History
Date Modified	Username	Field	Change
2009.03.10 13:58	tiico	New Issue
2009.03.10 13:58	tiico	browser	=> Mozilla
2009.03.10 13:58	tiico	MySQL version	=> MySQL: 5.0.67
2009.03.10 13:58	tiico	PHP version	=> PHP: 5.1.3RC4-dev
2009.03.10 13:58	tiico	Web server	=> Apache 1.3.x
2009.06.18 22:51	plg	Assigned To	=> plg
2009.06.18 22:51	plg	Status	new => assigned
2009.06.18 22:51	plg	Target Version	=> 2.0.3
2010.04.14 17:51	plg	Note Added: 0003765
2010.04.14 17:51	plg	Target Version	2.0.3 => 2.1.0RC3
2010.04.27 01:08	plg	Target Version	2.1.0RC3 => 2.1.0
2010.05.04 21:07	plg	Note Added: 0003834
2010.05.04 22:19	plg	Note Added: 0003835
2010.05.04 22:21	plg	Target Version	2.1.0 => 2.2
2011.01.18 15:52	plg	Target Version	2.2.0RC1 => 2.2.0RC2
2011.01.20 14:32	svn	Checkin
2011.01.20 14:32	svn	Note Added: 0004678
2011.01.20 14:33	plg	Status	assigned => closed
2011.01.20 14:33	plg	Resolution	open => fixed
2011.01.20 14:33	plg	Fixed in Version	=> 2.2.0RC1
2011.01.20 14:33	plg	Target Version	2.2.0RC2 => 2.2.0RC1
2011.01.20 16:28	rvelices	Note Added: 0004681
2011.01.20 16:28	rvelices	Status	closed => feedback
2011.01.20 16:28	rvelices	Resolution	fixed => reopened
2011.01.20 17:12	plg	Note Added: 0004682
2011.01.20 17:21	plg	Note Added: 0004683
2011.01.20 21:13	plg	Note Added: 0004684
2011.01.20 21:19	plg	Note Edited: 0004684
2011.01.20 21:33	rvelices	Note Added: 0004685
2011.01.20 21:33	rvelices	Status	feedback => closed
2011.01.20 21:33	rvelices	Resolution	reopened => fixed
2011.01.20 21:35	plg	Note Added: 0004686
2011.02.24 12:30	svn	Checkin
2011.02.24 12:30	svn	Note Added: 0004845
2011.05.02 15:40	plg	Relationship added	has duplicate 0001125

Notes
(0003765) plg (manager) 2010.04.14 17:51	That's OK to hide img1 only if img1 was not explicitely chosen as category representative photo => the category must have a random representative photo.

(0003834) plg (manager) 2010.05.04 21:07	In fact, it works fine if you have $conf['allow_random_representative'] = true; and not fixed a representative photo for a given category. But this is a very uncommon situation, simpy because by default $conf['allow_random_representative'] = false; (to reduce CPU load). I investigate on what can be done (without too many damages on CPU load) when the representative photo is defined. The problem is that it can be defined by user explicitely or automatically when adding photos. To avoid high CPU load (many queries), it would be better to have {category_id, privacy_level, representative_picture_id} and the corresponding user interface, but it's quite a huge job and certainly confusing for the vast majority of users.

(0003835) plg (manager) 2010.05.04 22:19	Another solution is to add a column "representative_picture_id" in the user_cache_categories table and fill it only when needed, so that for a given category and a given user the representative photo must be found only once (as long as there is no user cache reset). Adding this for Piwigo 2.1 is a bit too late, unfortunately :-/ 2.1.0RC3 is already available, and we're not supposed to modify the data model. And without modifying the data model, I don't know how to solve this problem efficiently. I have to postpone to Piwigo 2.2 :-/

(0004678) svn (reporter) 2011.01.20 14:32	[Subversion] r8802 by plg on trunk -----[Subversion commit log]---------------------------------------------------- bug 937 fixed: makes sure a user won't see the thumbnail of a photo that has a higher privacy level than user privacy level. For an acceptable solution at performance level, I have implemented a cache: for a given user, each album has a representative_picture_id. This cache also avoids to perform numerous "order by rand()" SQL queries which is the case when $conf['allow_random_representative'] = true;

(0004681) rvelices (developer) 2011.01.20 16:28	I have an issue with this commit for my config: - $conf[allow_random_representative']=false - some specific categories do not have representant because I want to search a representant of sub categories. Now with this change, you will save once an id in user_repres* and that's it.

(0004682) plg (manager) 2011.01.20 17:12	> Now with this change, you will save once an id in user_repres* > and that's it. Yes I know, this is the expected behavior. We lose a bit of randomness but it avoids numerous and heavy SQL requests. Do you suggest another way to solve this problem?

(0004683) plg (manager) 2011.01.20 17:21	We could not use the cache at all, but it is a nightmare at performance level in my opinion. We could only store the user_repres* if the found repres* level is higher than user.level but if the user is in this situation once, he loses the randomness for futur page refresh.

(0004684) plg (manager) 2011.01.20 21:13 edited on: 2011.01.20 21:19	I propose to keep this bug fixed (the bug itself is fixed) so that it appears as fixed for 2.2.0RC1. Please open a forum topic to discuss about the problem of the cache and the loss of randomness, we can change the algorithm for 2.2.0RC2 if we find a better solution.

(0004685) rvelices (developer) 2011.01.20 21:33	ok. let me see how i feel a week from now... maybe i'll love it

(0004686) plg (manager) 2011.01.20 21:35	You'll love the speed if you $conf['show_gt'] = true + $conf['show_queries'] = true But I agree that randomness was pleasant.

(0004845) svn (reporter) 2011.02.24 12:30	[Subversion] r9365 by plg on trunk -----[Subversion commit log]---------------------------------------------------- bug 937: problem on empty albums (visible for admins) with a representative_picture_id defined.