* chore(package): update apollo-cache-inmemory to version 1.6.6
* chore(package): update apollo-client to version 2.6.9
* chore(package): update apollo-utilities to version 1.3.4
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* Support Metadata in GridFSAdapter
* Useful for testing in the JS SDK
* Adds new endpoint to be used with `Parse.File.getData`
* Allows file adapters to return tags as well as future data.
* fix tests
* Make getMetadata optional
* Revert "fix tests"
This reverts commit 7706da13c688027483974e854b5b24321fb070cd.
* improve coverage
* chore(package): update @babel/core to version 7.9.6
* chore(package): update @babel/plugin-proposal-object-rest-spread to version 7.9.6
* chore(package): update @babel/preset-env to version 7.9.6
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params
* added ssl config params and others to PostgresConfigParser
* forgot to add back the original client file
* need to read in file at path for pfx, ca, key, and key
* convert file buffer to string to be consistant with node-postgres examples
* use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params
* Revert "use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params"
This reverts commit a5926d3ff7b97f72bb0c5bced15f34942cd1a96d.
* Updating travis postgres and removing unnecessary start of mongo-runner. Ensuring before_script and before_install matches the rest of travis
* Fixing objectId for Pointer in Postgres
* add test case for longer objectId pointer. Note that this test fails on Postgres before the addition of previous commit
* removed comment that wasn't needed
* Add test case for order option when extending the schema
* Remove fit
* upgrade to graphql-tools v5
revert #6515
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* chore(package): update apollo-link-http to version 1.5.17
* chore(package): update apollo-link-ws to version 1.0.20
* chore(package): update apollo-link to version 1.2.14
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* Apply linter changes on files I'm about to update
My actual changes were quite difficult to find when buried in this sea
of style changes, which were getting automatically applied during a
pre-commit hook. Here I just run the hooks against the files I'm going
to be touching in the following commit, so that a reviewer can ignore
these automatically generated diffs and just view the meaningful commit.
* perf: Allow covering relation queries with minimal index
When finding objects through a relation, we're sending Mongo queries
that look like this:
```
db.getCollection('_Join:foo:bar').find({ relatedId: { $in: [...] } });
```
From the result of that query, we're only reading the `owningId` field,
so we can start by adding it as a projection:
```
db.getCollection('_Join:foo:bar')
.find({ relatedId: { $in: [...] } })
.project({ owningId: 1 });
```
This seems like the perfect example of a query that could be satisfied
with an index scan: we are querying on one field, and only need one
field from the matching document.
For example, this can allow users to speed up the fetching of user roles
in authentication, because they query a `roles` relation on the `_Role`
collection. To add a covering index on that, you could now add an index
like the following:
```
db.getCollection('_Join:roles:_Role').createIndex(
{ relatedId: 1, owningId: 1 },
{ background: true }
);
```
One caveat there is that the index I propose above doesn't include the
`_id` column. For the query in question, we don't actually care about
the ID of the row in the join table, just the `owningId` field, so we
can avoid some overhead of putting the `_id` column into the index if we
can also drop it from the projection. This requires adding a small
special case to the MongoStorageAdapter, because the `_id` field is
special: you have to opt-out of using it by projecting `{ _id: 0 }`.
