Closed bwgjoseph closed 3 years ago
Here's another one
// instead of
{
$not: [{
$in : {
search_expr: 'model',
target_expr: ['767-300F'],
}
}]
}
// maybe
.find({
model : {
$nin: ['767-300F']
// or
$notIn: ['767-300F']
}
}
which is in line with the previous $in
suggestion
Will continue to list on as I discover more
so yeah the strong reason for doing it in a way it is today is more aligned with backward compatibility. If this is changed customers on 1.0 will have breaking changes.
I thought that there are already breaking changes in the API from v1 to v2, so this is actually a good chance to catch the train and make the changes altogether.
Check the most reason $in v2.0.0-beta.3 released
Hi,
I was wondering if
$in
(and maybe some other operator) could further simplify the usage?It definitely helps in DX as I would think that
search_expr
andtarget_expr
are not helping much here and could be abstracted away.I wasn't quite sure of how the other operators (especially
COLLECTION
) is used exactly, so not sure if those have special syntax like$in
and can be abstracted awayThanks