(sorry couldn’t think of a better name for the thread…)

In the last few days I’ve been trying to tackle a series of bugs having to do with listings of all kinds: uploads, playlists, feed items, search results, reviews, forum messages, etc. (Basically, pretty much the whole site.)

As I go around fixing those, a new version of the bug may, er, has shown up in areas that you may have noticed. Things like forum threads being cut off, clicking on a search result to be taken “nowhere” etc. These are new bugs introduced by the “fixes” in the paragraph above ;)

In all cases I’m doing my best to track them down and stomp on them - maybe it all sounds worse than it is but know that these are not “structural” flaws in the site, it’s typically a late-night typo and therefore (almost) always a very, very quick find and fix.

I’m sorry for any inconvenience these might have caused and appreciate your patience and really appreciate when these issues are reported to me.

Unlike some other software projects that I’ve worked on, both commercial and free/open, I have a “no known bugs” policy. iow when I am made aware of a bug I drop everything else to try to find it and fix it. If you see a bug, it’s because I missed it, not because I’m asking you to “live with it.”

for the geeks

Whereas in ccHost 4 the query engine was only used for upload listing, for 5 it is used for users, playlists, sample pool items, menus, and topics (which covers reviews, forum threads, special pages like ‘featured samples’, etc.) to name a few.

One of the shared parameters in all of those data sources is ‘limit.’ In order to do things “right” I felt I had to change the default behavior of how the absence of a ‘limit’ parameter is handled.

I forgot who said it but shared code means distributed bugs and I seem to be proving that every day with this one.

‘limit’ has the special feature of being able to hose the site if allowed unfettered access from the browser address bar. For example if we allowed just 2 people permission to do things like:

/api/query?tags=audio&limit=10000

the site would brought to it’s knees for everybody.

There are admin settable ‘limit’ maximum values in the system for 1) feeds, 2) page listings and 3) ‘other’ (general queries) to prevent this from happening.

Admins bury queries into navigation tabs (you can get a peak into the query behind a nav tab when you call up the feed for a page you landed on through a tab). Being admins, they need the ability to override the browser based ‘limit’, because (allegedly) we know what we’re doing.

And finally we have programmers who write queries directly into templates and code and they need to be able to override the admin settings because (allegedly) we are sent by the gods.

The formula I started using a few days ago goes like this:

limit=0

This means return all matching records.

If called from a browser this will be gated by the appropriate admin settable maximum limits.

If called from anywhere other than the browser, it really does means return everything.

limit=default
limit=

Leaving limit blank is now the same as saying ‘default.’ This means, use the admin settable limits, again based on format request, even if called from code.

limit=page|feed|query

This means use the admin settable limit for a particular setting. If calling from the browser it’s the same as saying either ‘0’ or ‘default’ or leaving it blank.

If called from code or a nav tab, it’s a way for the developer or admin to enforce and track the admin settable values for the current format.

limit=n

where n is a number.

If called from the browser n is bigger than the ‘default’ value, limit will be reset to ‘default’.

If called internally (code or navigation tab) n number of records will be returned.

——————————————————-

Throughout the code there was no limit setting which used to mean different things and the query engine did not have enough information to work consistantly. Hence the first wave of bugs.

The 2nd wave of bugs came when I changed to this new policy and missed several places (out of ~100) that needed to convert. Needless to say the last few days have proven that I didn’t catch all the cases… but I will at some point. Hopefully that point has passed but no guarantees.

VS

thanks for the geek version - knowing a bit of what’s happening under the covers without having to traverse php code is one of the hidden guilty pleasures for some of us. Kind of like reading about how George Martin used two 4 track decks for Sgt. Pepper :-)