Yes Mattz, that's why I pointed that, it's more easy and effective I think. You could just save the blocked items somewhere that may be even in your relational database in which your original application resides, and update them accordingly, and using them while querying. Or else you can save them in eventserver as a user properties and retrive them while querying. Both way it should be of help.
Thanks Vaghawan On Thu, Jul 27, 2017 at 11:44 AM, Mattz <[email protected]> wrote: > Thanks Vaghawan. I think using the "blacklistItems" might be better for my > use case rather than passing in the "block" events. I didn't think of this. > > On Thu, Jul 27, 2017 at 11:15 AM, Vaghawan Ojha <[email protected]> > wrote: > >> So you're not sending the blocklisted items in query like this right? >> >> "blacklistItems": ["itemId1", "itemId2", ...] >> >> So, you have those blocked events, then you must be able to update them >> accordingly just the way you set them as blocked. Or else I'm still not >> clear (I'm sorry in that case). >> >> Thanks >> Vaghawan >> >> On Thu, Jul 27, 2017 at 11:26 AM, Mattz <[email protected]> wrote: >> >>> This is how I am using now. I send a blocked event if a user blocks an >>> item. So, when recommending items for the user, this item does not show up. >>> I am using the "universal recommender" template. >>> >>> On Thu, Jul 27, 2017 at 11:09 AM, Vaghawan Ojha <[email protected]> >>> wrote: >>> >>>> Oh Yes Mattz, I seems to have misunderstood your situation. I thought >>>> that you were having that blocked prop as a properties or something. My >>>> thought must have been totally wrong. >>>> >>>> I'm not clear if you're sending the blocked items in query or something >>>> else? Also which template you have been using? >>>> >>>> Thanks >>>> >>>> >>>> >>>> On Thu, Jul 27, 2017 at 11:19 AM, Mattz <[email protected]> wrote: >>>> >>>>> Thanks Vaghawan. "$set" and "$unset" are used to set/unset item >>>>> properties right? Since these are not like the other events, these items >>>>> would still be returned unless I manually find all the things blocked and >>>>> filter from list to get my result set. But, if I send "blocked" as a >>>>> regular event, PIO automatically filters out items that were blocked by >>>>> the >>>>> user. >>>>> >>>>> On Thu, Jul 27, 2017 at 10:59 AM, Vaghawan Ojha <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi Mattz, >>>>>> >>>>>> You could just use $set, $unset to achieve this. When user wish to >>>>>> unblock the item, just send in another request in the event server to >>>>>> update the event. This would solve your problem from as much as I know >>>>>> from >>>>>> using pio eventserver. >>>>>> >>>>>> you could find the examples here. https://predictionio.inc >>>>>> ubator.apache.org/datacollection/eventmodel/ >>>>>> >>>>>> Thanks >>>>>> Vaghawan >>>>>> >>>>>> On Thu, Jul 27, 2017 at 11:09 AM, Mattz <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I have a use case where I am sending a "blocked" event for a user >>>>>>> for a particular item. When this happens, PIO eliminates this item from >>>>>>> the >>>>>>> result set. But, the user can choose to "unblock" this item at a later >>>>>>> time. I am wondering how to handle this. Should I somehow delete the >>>>>>> event >>>>>>> from the even server? If yes, how? Is there any other way to solve this? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
