-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improper handling of query parameters depending on their order for relational arrays. #3169
Comments
I encounter the same problem. Any updates on that? |
I'm trying to understand why & where this occurs. It's a bit early but it looks like relying on indexes somewhere here in MongoTransform.js could be the reason. Is anyone currently on this issue? |
I'll try to have a look before end of week |
@lenart @flovilmart thanks for looking at the issue. I was loosing hope already ;) I will take a look at what @lenart suggested. |
I haven't had time to give it much toughts last week. Any progress on investigating? That should be quite trivial to solve. |
Thanks for follow up @flovilmart. Unfortunately I haven't able to get the resources needed to implement a proper fix for this issue. We've decided to workaround using a middleware that reorders the input params for For the impatient ones here's the code // /index.js
var app = express();
...
app.use(bodyParser.json());
var PointerParamsFix = require('./lib/pointer-params-fix');
app.use(PointerParamsFix);
... and the middleware // /lib/pointer-params-fix.js
// Middleware for reordering params for Pointer objects
// -----------------------------------------------------
// Without this middleware parse-server responds with an empty array each time
// Pointer properties are not in this order: __type, className, objectId.
// This script checks the params and reorders any Pointer objects found
//
// Github Issue: https://github.com/ParsePlatform/parse-server/issues/3169
var PointerParamsFix = function(req, res, next) {
var where = req.body.where
if (where) {
for (var key in where) {
if (where[key].hasOwnProperty('__type')) {
if (where[key].__type === 'Pointer') {
where[key] = {
"__type": where[key].__type,
"className": where[key].className,
"objectId": where[key].objectId,
}
}
}
}
}
next();
};
exports = module.exports = PointerParamsFix; I know this requires to inject this middleware each time |
I set up parse server, did the debugging and spotted the consequent issue. If query parameters inside where statement are in incorrect order (e.g. className after objectId),
then method named This behaviour is caused by Modifying |
@lenart Thanks for your solution. I found that it did not cover all the cases for nested queries, such as $or or matching queries. Based on your solution I updated it to iterate the entire where object and update all pointers recursively. // /lib/pointer-params-fix.js
// Middleware for reordering params for Pointer objects
// -----------------------------------------------------
// Without this middleware parse-server responds with an empty array each time
// Pointer properties are not in this order: __type, className, objectId.
// This script checks the params and reorders any Pointer objects found
//
// Github Issue: https://github.com/ParsePlatform/parse-server/issues/3169
var PointerParamsFix = function(req, res, next) {
var where = req.body.where
RecusivePointerParamsFix(where);
next();
};
var RecusivePointerParamsFix = function(object) {
if (object) {
for (var key in object) {
if (object[key].hasOwnProperty('__type')) {
if (object[key].__type === 'Pointer') {
object[key] = {
"__type": object[key].__type,
"className": object[key].className,
"objectId": object[key].objectId,
}
}
} else if (Array.isArray(object[key])){
for (var subKey in object[key]) {
RecusivePointerParamsFix(object[key][subKey]);
}
} else if (object[key] != null && typeof object[key] == 'object') {
RecusivePointerParamsFix(object[key]);
}
}
}
};
exports = module.exports = PointerParamsFix; |
I completely dropped the ball on that one, need to look it up a bit more. |
During investigation of iOS SDK bug parse-community/Parse-SDK-iOS-OSX#1067 I've noticed that one of my queries fails when working on 32 bit device. At first, I thought it's due to recent SDK update from 1.13.0 to 1.14.2 but I was able to reproduce it with both SDK versions. After few hours of debugging how requests are made on 32/64 bit SDK I came to conclusion that ParseServer treats differently requests that queries fields with one direct object pointer vs array of those pointers. Because of the way how iOS SDK stores request parameters internally (in NSDictionary which is unordered collection) JSONs producend on 32 bit devices are different then the one from 64 bit devices (presented below) and requests on 32 bit devices is failing.
Steps to reproduce
I'll also present case where this doesn't matter due to fact that fields containg just one relation objects are stored differently by ParseServer
Expected Results
Ordering of parameters in both queries should not influence results.
Actual Outcome
1. Query on array field
Produced JSON on 32 bit devices:
Produced JSON on 64 bit devices:
Result:
On 64 bit devices all values are returned correctly, on 32 bit empty array is returned(refer to logs section)
2. Query on direct releation field
32 bit device:
64 bit device
Result:
In both cases proper values is returned
Environment Setup
Server
Database
Logs/Trace
1. query on relation array
64 bit request/response log from server:
32 bit request/response log from server:
2. query on direct relation field
64 bit request/response log from server
32 bit request/response log from server:
I guess that if field contains direct relation to object query is translated from above form to CLASS_NAME$OBJECT_ID before sending it to MongoDB, and in case of field containg array query from above is passed directly to MongoDB which is why it's returning 0 objects. So either such translation should happen in both cases or SDK should create queries in specific order (although I coulnd't find any statement in documentation for REST Api about such requirement) or maybe there's a way to convince MongoDB to not look at parameter order, just "content".
The text was updated successfully, but these errors were encountered: