crud Jaybell/crud mongoose query params

May 14 '20 03:05 yharaskrik

Hey @arrrrny coming back to this after a while I fixed #435 first but I will try and look into your populate issue and decoupling from typeORM

May 14 '20 03:05 yharaskrik

This still needs quite a few unit tests to test the filter, or and search on GET's but the issues mentioned in #435 should be fixed.

May 14 '20 03:05 yharaskrik

@yharaskrik thanks bro

May 14 '20 03:05 arrrrny

@yharaskrik please ping me when I can merge it

May 14 '20 03:05 michaelyali

@zMotivat0r will do. I would like to get the test coverage up a bit before that happens just to make sure that the filters are being built correctly. And to test that populate issue.

May 14 '20 03:05 yharaskrik

Awesome

May 14 '20 03:05 michaelyali

I had to rework how the crud request interceptor works a small amount to ensure that some of the operators that are allowed can be used with mongoose.

There is now an OPERATOR_MAP optional injection token that can customize the crud request parsing. Since mongoose does not use SQL to query some operators do not map 1:1 like in TypeORM.

Can be provided like this:

{
   provide: OPERATOR_MAP,
   useValue: MONGOOSE_OPERATOR_MAP,
}

This injection token is optional and if not provided will use the operators as is to query the DB.

This will also allow for more Databases if they happen to use different syntax.

One side effect of this that may need to be addressed is that the operators that are used after transformation with the operator map may need to be whitelisted in the validate operator function in the interceptor.

This also decouples from TypeORM and adds DeepPartial to the utils.

Something to note: The operator map is only needed for mongoose if you are using operators that are not directly supported by mongoose. And not all operators are supported yet, the ones currently supported are:

eq
ne
gt
lt
gte
lte
in
notin
isnull
notnull
between
starts
end
cont
excl

Not sure if this is quite the best way to go, open to suggestions of how we can breach the gap between NoSQL query language (currently mongodb) and SQL. With the changes that I made I do not think we would be able to use more than one DB type with this package, although not sure if that was possible before or not either.

May 18 '20 23:05 yharaskrik

Is there any roadmap to merge this?