BREAKING CHANGE: `Parse.Query` no longer supports the BSON type `code`; although this feature was never officially documented, its removal is announced as a breaking change to protect deployments where it might be in use.
BREAKING CHANGE: The MongoDB aggregation pipeline requires native MongoDB syntax instead of the custom Parse Server syntax; for example pipeline stage names require a leading dollar sign like `$match` and the MongoDB document ID is referenced using `_id` instead of `objectId` (#8362)
BREAKING CHANGE: Nested objects are now properly stored in the database using JSON serialization; previously, due to a bug only top-level objects were serialized, but nested objects were saved as raw JSON; for example, a nested `Date` object was saved as a JSON object like `{ "__type": "Date", "iso": "2020-01-01T00:00:00.000Z" }` instead of its serialized representation `2020-01-01T00:00:00.000Z` (#8209)
BREAKING CHANGE: The MongoDB GridStore adapter has been removed. By default, Parse Server already uses GridFS, so if you do not manually use the GridStore adapter, you can ignore this change.
* Added a test case that triggers the query parameter crash
* rest.js: validate the explain parameter to keep the nodejs driver from throwing an uncatchable exception and crashing the server (see https://jira.mongodb.org/browse/NODE-3463)
RestQuery.js: Check whether explain mode is enabled not by "!== true", but by the "!" operator. explain can have string values.
Added tests that validate correct behaviour on different explain values
* Refactor the new tests
* Simplify the new tests
Also do a sanity check on the explain results
* Test refactor
* Exclude queryPlannerExtended as it is not supported by the testing environment
Simplifies the tests
* Restrict the changes to mongodb
Moved the verification of the explain value from rest.js to MongoStorageAdapter.js
Also restricted the relevant unit tests to mongodb
* Added changelog entry
* reformat changelog entry
* Update CHANGELOG.md
Co-authored-by: Kartal Kaan Bozdoğan <kartalkaanbozdogan@gmail.com>
Co-authored-by: Manuel <5673677+mtrezza@users.noreply.github.com>
* Fixed a bug affecting updates to nested pointers
Also created unit tests
* Marked the regression test for #7391 as pending for postgre
The issue is not fixed yet
Use cont instead of var
* Fix flaky test with transactions
* Add CHANGELOG entry
* Fix the other transactions related tests that became flaky because now Parse Server tries to submit the transaction multilpe times in the case of TransientError
* Remove fit from tests
* Update PostgresStorageAdapter.js
Improve `createClass` transaction:
* `await` makes it a more consistent sequence of queries
* `batch` is not needed there
* No need for an extra `.then` section
* Update PostgresStorageAdapter.js
Remove batch-dependent error code check, as it should happen automatically without batch result.
* Update PostgresStorageAdapter.js
Removing unused variable.
* prepend className to unique index to allow multiple unique indexes for different classes
* add testcase
* switched test so it can be tested on older versions of parse-server and show failure
* get rid of console log messages on restart by checking if the index exists before creating it
* add IF NOT EXISTS and IF EXISTS to ALTER TABLE
* revert some of code
* ensureIndex use IF NOT EXISTS
* ALTER TABLE CONSTRAINT can't use IF, ADD/DROP COLUMN can
* retesting
* update
* switchted to CREATE UNIQUE INDEX instrad of ALTER TABLE... ALTER TABLE doesn't seem to be needed
* Optimize query, fixes some null returns, fix stitched GraphQLUpload
* Fix authData key selection
* Prefer Iso string since other GraphQL solutions use this format
* fix tests
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* add test cases for geoNear aggregation
Test cases do not have the `query` parameter set in $geoNear aggregation stage. this is to test for a reported potential issue when the parameter is not set.
* fixed potential issue when setting the geoNear.query parameter to undefined
see dicussion in https://github.com/parse-community/parse-server/pull/6540
* fixed duplicate index name in test
* 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
* 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
* 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 }`.
