Issues with objects from more than one relationship in ERRest

[pascalrobert]

In a project I'm working on with other people, we found an unexpected behavior with filters. If the response have two relationships that points to the same objects, but they are not filtered with the same attributes, the same filter will apply to both.

Example:

ERXKeyFilter showFilter = ERXKeyFilter.filterWithNone();
showFilter.include(User.PARTY.dot(Party.PRODUCTS)).includeAttributes() ; showFilter.include(User.PARTY.dot(Party.CLIENTTIER).dot(Clienttier.CLIENTTIER_SPREADS).dot(ClienttierSpread.PRODUCTS).dot(Product.PRODUCT_NAME));

In the response, for User.PARTY.dot(Party.PRODUCTS)).includeAttributes(), only the product name will be displayed because of the other filter (ClienttierSpread.PRODUCTS).dot(Product.PRODUCT_NAME)). If a product inside party.products don't exist in clienttierSpread.products, all attributes will be show, the "problem" only occurs if a product is in both relationships.

[mschrag]

My version is pretty different than the public one these days, but this problem sounds similar. This is likely not a "bug" per se, but a side effect of de-duping. With de-duping on, the first definition of an object in the stream wins. So if you have de-duping on, you should make sure to share the same filter definition for every place where you can reach your object because you don't know which one will be found first. Is sort of debatable whether de-duping should consider those to be different based on gid+filter rather than just gid .... I could make a case either way, I think, but as it is, it is at least surprising.

[paulhoadley]

Is Mike's explanation sufficient to close this ticket, Pascal? Or do you want to consider changing the behaviour observed?

[mschrag]

I don't think it's close-worthy. It's just not clear what the right fix is ... maybe deduping needs to track object + filter as the hash key or something.