Author information block seems to be broken [#27948]

Comment	File	Size	Author
#2	profile_1.patch	1.12 KB	killes@www.drop.org

#1	profile.module_2.patch	1.09 KB	tostinni

Comment #1

tostinni CreditAttribution: tostinni commented 11 August 2005 at 23:08

Status:

Active

» Needs review

File	Size
profile.module_2.patch	1.09 KB

This little patch does the trick.
The bug came from the fact that the query retrieving user profiles, didn't take all public fields.

Log in or register to post comments

Comment #2

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 1 September 2005 at 18:57

File	Size
profile_1.patch	1.12 KB

I've looked at the patch, changes "in" to "IN" and removed trailign DOS newlines, and can confirm that it works.

Log in or register to post comments

Comment #3

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 1 September 2005 at 18:58

Status:

Needs review

» Reviewed & tested by the community

changing status

Log in or register to post comments

Comment #4

Dries CreditAttribution: Dries commented 2 September 2005 at 07:21

Is using IN() equivalent to using OR or is one faster than the other?

Log in or register to post comments

Comment #5

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 2 September 2005 at 12:47

Cvbge and I think that it is equivalent in this case. it is unsure whether it is faster, but IN () is usually regarded as being fast:
http://mysql.com/in

Log in or register to post comments

Comment #6

tostinni CreditAttribution: tostinni commented 2 September 2005 at 13:28

I'm not a DB expert, but I got a little experience on Oracle (great you can answer ;) but I think it should happen pretty much the same), so IMVHO, I think that they're doing the same, in fact, looking at Oracle explain plan, it's exactly the same between a OR and a IN clause. They both do the same explain plan using "INLIST ITERATOR" in fact, the cost is the same, but explain plan tells me that it takes slightly less bytes to achieve it...
Ok sorry if very off topic and useless, but I thought it worthes to mention that.

Back to our query, I think whatever we put OR or IN clause, we shouldn't expect speed problem with this, as it's very little the change. If we do care about it, I think we should add an INDEX on this column. Also, I think IN clauses in this case (using 2 or more coma separated values) is much clearer than writing a lot of OR.