doesNotMatchKey: inQuery: returnne les loggings qui correspondent à la key dans Parse SDK pour iOS

J'essaie de faire une requête simple dans xcode en utilisant le SDK Parse où je montre des produits aux users mais je ne veux pas leur montrer les produits qu'ils ont déjà "aimé".

J'ai donc deux tables dans Parse que j'utilise:
– Products: a un objectId
– J'aime: contient des colonnes: J'aime (dit oui / non), Pointeur vers un produit, Pointeur vers un user

Tout mon code est:

//query will get products that the user has liked PFQuery *likeQuery = [PFQuery queryWithClassName:@"Likes"]; [likeQuery whereKey:@"User_Obj" equalTo:[PFUser currentUser]]; //product query will get products that are not in like query PFQuery *prodQuery = [PFQuery queryWithClassName:@"Products"]; [prodQuery whereKey:@"objectID" doesNotMatchKey:@"Product" inQuery:likeQuery]; //ressortingct to 10 items [prodQuery setLimit:10]; [prodQuery findObjectsInBackgroundWithTarget:self selector:@selector(getCallback:error:)]; 

Toutefois, lorsque j'essaie d'exécuter ces éléments précédemment aimés par cet user sont renvoyés.

Si je faisais ça en SQL, j'écrirais quelque chose comme:

 SELECT product FROM product WHERE product NOT IN (SELECT product FROM likes WHERE useriD = currentUser AND like = yes) 

Toute aide serait très appréciée!

Merci, Tim

En travaillant avec Parse et d'autres services NoSQL, vous devez vous libérer de l'état d'esprit SQL (avec normalisation, etc.). Les "schémas" NoSQL sont axés sur l'efficacité des requêtes plus que sur le stockage et la cohérence. Vous pouvez, comme le suggère Petro, stocker tous vos goûts dans un tableau dans la table des users. Vous pouvez ensuite interroger Parse avec une contrainte indiquant que les loggings ne doivent correspondre à aucun objectid dans votre requête, comme ceci:

 [query whereKey:@"objectId" notContainedIn:user.productLikes]; 

où productLikes est le tableau des ID de produit.

Une autre solution consisterait à stocker les preferences du produit dans une table différente, mais toujours sous la forme d'un tableau (pas d'loggings séparés pour chaque type, avec des pointeurs vers des produits et des users comme vous l'auriez fait avec une database SQL). Dans ce cas, vous pouvez imbriquer les requêtes comme vous l'avez fait dans votre question.