Open aaronjwhiteside opened 3 years ago
That can be a good addition, need to think about the naming, collection is too narrow, should be iterable or group to include arrays or have different method for iterables and arrays.
I'd be ok with two methods, one for Iterables, and another for arrays. But you'd probably need another one for Maps too, as the Map interface doesn't extend Iterable.
And if we keep following this train of through, I can foresee the need for comparing objects where one has an Optional<T>
and another the raw/unwrapped nullable T
field. Even though it's frowned upon to use Optional in fields, I still occasionally see and have to deal with it.
You can probably also argue that this should extend to the Atomic* family of value wrappers too.
Could I try to contribute to this new feature? @joel-costigliola
@Zhou-Yicheng thanks but it's not ready yet to be picked, the team need to decide the way to go.
This would be a very useful addition for those of us working with JPA models. Currently even coming up with an acceptable workaround is tricky.
Really need this feature
Summary
Currently when comparing two representations of the same entity from different domains/models, where one has null for a collection and the other has an empty collection, there is no option to treat these fields as being equal.
I can see there are options for
.ignoringActualNullFields()
and.ignoringExpectedNullFields()
, but these options have other ramifications, when all I want to do is treat null and empty collections as matching.I propose that a new option be introduced, something like
Example