Every API request that allows a ?page= parameter to be passed in also includes a pagination property in the resultset. Different API requests (members vs posts, for example) have a different number of results per page. The number matches up to how many results per page for each data type on production DaniWeb, and the number is always included in the pagination property.
The results aren't random. What is happening is if you select a page that is higher than the number of available pages given your filter parameters, it removes the filter parameters and keeps the page number. Will fix the bug shortly.
I wasn't aware of the php port. I assumed it was .net
However, not having much to do with it - at all really - I think MySQL flavour of SQL will be easier for users. I just looked at PHPLinq and it looks a little more involved.
Just to give you an idea, this code:
$dw = new dwQuery;
print_r($dw->query("SELECT `id`, `username`, `group` FROM `members` LIMIT 10"));
So I'm quite pleased with it so far. The WHERE and ORDER BY clauses are giving me a bit of a headache though. The ORDER BY, I'll do with a multisort function, but the WHERE clause - yuk!
Problem with all the possible logical and other operators e.g. LIKE / IN and nesting of subclauses. It's all good stuff though! I'm looking at an eval() solution, but that makes me very nervous. :(
Problem with all the possible logical and other operators e.g. LIKE / IN and nesting of subclauses.
Basically all of the filtering / sorting that we provide through the API is limited to the functionality that is needed for the existing DaniWeb website. (Effectively giving you the ability to recreate a production DaniWeb).
Unfortunately we can't provide every possible combination of filtering because the sky is the limit when it comes to potential uses and possibilities, beyond what we already do on the DaniWeb website. For example, the only filtering we currently do here is allow moderators to search by username, which is functionality built into the API.
In a production environment, you might actually wish to consider recreating a database (or perhaps a no-sequal database such as MongoDB) from the API requests, and then querying your own database.
Thanks Dani. Your last suggestion sounds very useful. My solution at the moment is based on a normal API call coming from an SQL-like syntax query, where the where clause is parsed to strip out bona fide API filters and 'other' filters. The api filters are applied in the usual way to the url, but then the resulting array is spliced and diced with the 'other' filters.
I was hoping to just create a class that did all this, so that users could just 'include it and go' - if they had a client id / secret key. Mongo or NoSQL would require additional messing about - but I may bite the bullet and consider it as I'm finding the parsing a little heavy going. :(
AND|OR|NOT|+|LIKE|IN|=|>=|<=|<>|!= and countless other reserved words and fieldname combos and blasted nesting... Regex is just not my thing and it's really not up to the task of dealing with SQL.