Open pfurini opened 8 years ago
You could do this with a joi valiator
I read the reply to the issue on tastypie-rethink, and the custom field type is a feasible option. But I don't think a validator could do the job.. The problem here is a filter's value in the query string, while a validator works on the request's body.
In the linked issue you say
things in an array can get complex and not guaranteed to be homogeneous.
while I agree with you in a more broader sense, I think it's common in the majority of ORMs to pose some restriction on array elements' type.
In some RDBMS (for example Postgres) it's even mandatory to have homogeneous type in array fields (an array field is declared like integer[]
).
so, IMHO, the use case for an array type specifier is so common that it should be considered to be an upstream feature..
P.
I see where you are coming from, I do. However, I think the most common use case is just parse out an array. It is the least invasive, least prone to error ( from a functional standpoint ), is the most performant, and leans heavily on Javascript's native behavior. Which is the way I think it should stay.
I could see this a special filed type SmartArray
either as a stand alone npm package or maybe a PR.
Is there an option to specify the type of elements in an array? If not it should be added to fix a problem with the
match
filter in resource implementations liketastypie-rethink
. Here the match filter does not work if you declare the array type as string in thinky, and you pass a filter value that is coercible to number, for exampleextCategories__match=123
. The only elegant way around this is to have an array type option and cast the filter value accordingly before passing it to thematch
filter.