[Solved] webservice - none or too few results (1.5.3.1)

[irrelevant]

Ok; I'm pulling my hair out here.

 

 

 

Most of my stock is being imported from csv at the moment until I can code up a webservice-based front end. So, it ends up without ASM enabled on the products. I've got a script that does use the API, fetches all products, and sets the value as necessary.

 

But it only worked for the first 500 products or so -

 

A simple -

https://www.example....roducts/?filter[advanced_stock_management]=[0]&display=[id]

 

gives me no results ...

 

Whereas checking the database shows I've still got 224 products that satisfy this criteria...

 

mysql> select id_product from ps_product where advanced_stock_management = 0 limit 10;
+------------+
| id_product |
+------------+
| 640 |
| 646 |
| 793 |
| 794 |
| 796 |
| 798 |
| 799 |
| 800 |
| 801 |
| 802 |
+------------+
10 rows in set (0.00 sec)

 

 

If I view, without any filtering, https://www.example....s/api/products/

 

I get a list up to id 792. It definitely misses out all of the products that the sql query returned (which are presumably still unset because the first time round it didn't find them) but I've not checked if any others are missing. (I've got some gaps from deleted items anyway.)

 

 

Is there something that limits the number of results that can be processed, or otherwise ignores some product records, even if no filters are set?

 

 

Edit:

OK. Solved it. I'm running multi-store. The "missing" products are in a secondary shop on a different domain name to primary store, whose url the webservice was being accessed from. Switching to the other domain name returns all the other results. So, despite the key being set for all-shops, requests only return items relating to the shop in the URL. I can't see an obvious way of specifying "all shops".

 

Edit2:

Adding id_shop=2 (or 1) to the URL works to switch stores, but the source code implies id_shop=all should work, but this fails. Adding [ ] to the parameters doesn't work at all.

Edited July 22, 2013 by irrelevant (see edit history)