Gathering detailed insights and metrics for @tranminhhoang2/objection-filter
Gathering detailed insights and metrics for @tranminhhoang2/objection-filter
Gathering detailed insights and metrics for @tranminhhoang2/objection-filter
Gathering detailed insights and metrics for @tranminhhoang2/objection-filter
npm install @tranminhhoang2/objection-filter
Typescript
Module System
Min. Node Version
Node Version
NPM Version
73.2
Supply Chain
99
Quality
75.1
Maintenance
100
Vulnerability
99.6
License
JavaScript (100%)
Total Downloads
803
Last Day
1
Last Week
2
Last Month
3
Last Year
81
1 Commits
1 Watching
8 Branches
1 Contributors
Latest Version
1.0.1
Package Id
@tranminhhoang2/objection-filter@1.0.1
Unpacked Size
137.47 kB
Size
22.27 kB
File Count
28
NPM Version
6.13.4
Node Version
10.18.0
Cumulative downloads
Total Downloads
Last day
0%
1
Compared to previous day
Last week
0%
2
Compared to previous week
Last month
-57.1%
3
Compared to previous month
Last year
-46%
81
Compared to previous year
objection-filter is a filtering module for the objection.js ORM. It was originally based on objection-find, but has since moved in a different direction. It aims to fulfil some requirements that occur often during API development:
For example, if you have the models Customer belongsTo City belongsTo Country, we can query all Customers where the Country starts with A
.
Eagerly load a bunch of related data in a single query. This is useful for getting a list models e.g. Customers then including all their Orders in the same query.
objection-filter >= 1.0.0 is fully backwards compatible with older queries, but now supports nested and/or filtering as well as the new objection.js object notation. The 1.0.0 denotation was used due to these changes and the range of query combinations possible.
The filtering library can be applied onto every findAll REST endpoint e.g. GET /api/{Model}?filter={"limit": 1}
A typical express route handler with a filter applied:
1const { buildFilter } = require('objection-filter'); 2const { Customer } = require('./models'); 3 4app.get('/Customers', function(req, res, next) { 5 buildFilter(Customer) 6 .build(JSON.parse(req.query.filter)) 7 .then(customers => res.send(customers)) 8 .catch(next); 9});
Available filter properties include:
1// GET /api/Customers 2{ 3 // Filtering and eager loading 4 "eager": { 5 // Top level $where filters on the root model 6 "$where": { 7 "firstName": "John" 8 "profile.isActivated": true, 9 "city.country": { "$like": "A" } 10 }, 11 // Nested $where filters on each related model 12 "orders": { 13 "$where": { 14 "state.isComplete": true 15 }, 16 "products": { 17 "$where": { 18 "category.name": { "$like": "A" } 19 } 20 } 21 } 22 }, 23 // An objection.js order by expression 24 "order": "firstName desc", 25 "limit": 10, 26 "offset": 10, 27 // An array of dot notation fields to select on the root model and eagerly loaded models 28 "fields": ["firstName", "lastName", "orders.code", "products.name"] 29}
The
where
operator from < v1.0.0 is still available and can be combined with theeager
string type notation. The same is applicable to therequire
operator. For filtering going forward, it's recommended to use the objection object-notation for eager loading along with$where
definitions at each level.
There are a number of built-in operations that can be applied to columns (custom ones can also be created). These include:
An example of operator usage
1{ 2 "eager": { 3 "$where": { 4 "property0": "Exactly Equals", 5 "property1": { 6 "$equals": 5 7 }, 8 "property2": { 9 "$gt": 5 10 }, 11 "property3": { 12 "$lt": 10, 13 "$gt": 5 14 }, 15 "property4": { 16 "$in": [ 1, 2, 3 ] 17 }, 18 "property5": { 19 "$exists": false 20 }, 21 "property6": { 22 "$or": [ 23 { "$in": [ 1, 2, 3 ] }, 24 { "$equals": 100 } 25 ] 26 } 27 } 28 } 29}
Logical expressions can be applied to both the eager
and require
helpers. The where
top level operator will eventually be deprecated and replaced by the new eager
object notation in objection.js.
$where
The $where
expression is used to "filter models". Given this, related fields between models can be mixed anywhere in the logical expression.
1{ 2 "eager": { 3 "$where": { 4 "$or": [ 5 { "city.country.name": "Australia" }, 6 { "city.code": "09" } 7 ] 8 } 9 } 10}
Logical expressions can also be nested
1{ 2 "eager": { 3 "$where": { 4 "$and": { 5 "name": "John", 6 "$or": [ 7 { "city.country.name": "Australia" }, 8 { "city.code": { "$like": "01" }} 9 ] 10 } 11 } 12 } 13}
Note that in these examples, all logical expressions come before the property name. However, logical expressions can also come after the property name.
1{ 2 "eager": { 3 "$where": { 4 "$or": [ 5 { "city.country.name": "Australia" }, 6 { 7 "city.code": { 8 "$or": [ 9 { "$equals": "12" }, 10 { "$like": "13" } 11 ] 12 } 13 } 14 ] 15 } 16 } 17}
The $where
will apply to the relation that immediately precedes it in the tree, in the above case "city". The $where
will apply to relations of the eager model using dot notation. For example, you can query Customers
, eager load their orders
and filter those orders by the product.name
. Note that product.name
is a related field of the order model, not the customers model.
If the built in filter operators aren't quite enough, custom operators can be added. A common use case for this may be to add a lower case string comparison
operator, which may vary in implementation depending on the SQL dialect.
Example:
1const options = { 2 operators: { 3 $equalsLower: (property, operand, builder) => 4 builder.whereRaw('LOWER(??) = LOWER(?)', [property, operand]) 5 } 6}; 7 8buildFilter(Person, null, options) 9 .build({ 10 eager: { 11 $where: { 12 firstName: { $equalsLower: 'John' } 13 } 14 } 15 })
The $equalsLower
operator can now be used as a new operator and will use the custom operator callback specified.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 0/1 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
no SAST tool detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
project is not fuzzed
Details
Reason
126 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-12-16
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More