docs: add decision record about IDS filtering

[maciejkizlich-zf]

What this PR changes/adds

Add decision record about filtering ContractOffers by Asset's properties.

Linked Issue(s)

Filter catalog by assets properties

Checklist

• added appropriate tests?
• performed checkstyle check locally?
• added/updated copyright headers?
• documented public classes/methods?
• added/updated relevant documentation?
• assigned appropriate label? (exclude from changelog with label no-changelog)
• formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

[paullatzelsperger]

comments inline.

[paullatzelsperger]

IMO this section can be shortened because only two things need to be done:

• replace the use of Range (for paging) with QuerySpec, for full querying capabilities
• swap out the (flattened) serialization of the Range with object serialization of the QuerySpec

[maciejkizlich-zf]

Done.

[paullatzelsperger]

Done.

nope, not quite :) Please highlight that transmitting the Range needs to be replaced by transmitting the entire QuerySpec. Filtering is only one aspect of it. Sorting is another.

[ndr-brt]

@paullatzelsperger I'm not sure that introducing QuerySpec is the way to go, since the "range" part actually doesn't limit ContractOffers, but ContractDefinition (if you request a catalog with 50 item you could end up receiving more than 50 contract offers, because of the flatMap behavior in the service), while the criteria part would filter only the Assets.
In my opinion the ContractOfferQuery object should be used, adding definitionsRange and assetCriteria fields, this will make the process explicit

[maciejkizlich-zf]

@paullatzelsperger what do you think about @ndr-brt reasoning? I agree with such argument.

[paullatzelsperger]

@ndr-brt @maciejkizlich-zf here's a weird thing: ContractOfferQuery.getCriteria(), .getOffset() and .getLimit() appear not to be used anywhere, at least IntelliJ doesn't report any findings.
Could we just use those fields? We might even be able to remove the range parameter from the ContractOfferServiceImpl.queryContractOffers then.

I agree with the opinion that query parameters should affect the list of assets/offers, not the definitions. If that's the case it needs to get fixed.

[paullatzelsperger]

@maciejkizlich-zf could you adapt your PR as per my last comment regarding the ContractOfferQuery?

[maciejkizlich-zf]

@paullatzelsperger please take a look now, I've added a part regarding ContractOfferQuery.

And yes, we should be able to remove Range from the queryContractOffers(). Also, I'd replace .getOffset and getLimit() with just getRange().

[paullatzelsperger]

Done.

nope, not quite :) Please highlight that transmitting the Range needs to be replaced by transmitting the entire QuerySpec. Filtering is only one aspect of it. Sorting is another.

[juliapampus]

@paullatzelsperger We will just ignore the fact that there is an IDS message type in place that is designed for passing query statements, right? Paging was an issue, but querying has already been considered, even before to the current discussions.

[paullatzelsperger]

@paullatzelsperger We will just ignore the fact that there is an IDS message type in place that is designed for passing query statements, right? Paging was an issue, but querying has already been considered, even before to the current discussions.

@juliapampus Which message would that be? Generally though, we're adding features to a stack that will get replaced in the very near future (i.e. IDS Multipart), so I would like to keep the change small and simple

[juliapampus]

@paullatzelsperger We will just ignore the fact that there is an IDS message type in place that is designed for passing query statements, right? Paging was an issue, but querying has already been considered, even before to the current discussions.

@juliapampus Which message would that be? Generally though, we're adding features to a stack that will get replaced in the very near future (i.e. IDS Multipart), so I would like to keep the change small and simple

For the record: We discussed this bilateral. Correct IDS messages would be QueryMessage with ResultMessage as response. This would end up in a separate sender and handler class which would be a cleaner approach, but goes beyond the current scope.