Skip to content
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

query.include is not including what it should #32

Closed
marlonguerios opened this issue Sep 30, 2015 · 26 comments
Closed

query.include is not including what it should #32

marlonguerios opened this issue Sep 30, 2015 · 26 comments
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@marlonguerios
Copy link

After I changed the Parse version to 1.6.4, query.include stopped working and it is not including the data from the pointer. There was no changes to my code, only the Parse version. When I revert Parse version back to 1.6.2 query.include is works fine again, but I can't use 1.6.2 because of the Relations bug that was fixed on 1.6.4.

@marlonguerios
Copy link
Author

just tried changing Parse version to latest instead of 1.6.4 and query.include is working. I wonder what is the problem with setting the Parse version to 1.6.4 through parse jssdk 1.6.4?

@parse-github-bot
Copy link

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

@marlonguerios
Copy link
Author

Here is the code:

var query = new Parse.Query("Menu");
        query.equalTo("objectId", req.params.menuId);
        query.find().then(function (menu) {
            var relation = menu[0].relation("sections");
            var relQuery = relation.query();
            relQuery.include("pdName");
            return relQuery.find();
        }).then(function (sections) {
            var json = {
                draw: draw,
                data: sections,
                recordsFiltered: sections.length,
                recordsTotal: sections.length
            };
            res.json(json);
        }, function (error) {
            res.json(error);
        });

Here is what I get for the field pdName for version 1.6.4:

      "pdName": {
        "__type": "Pointer",
        "className": "PhraseDictionary",
        "objectId": "8N1TwAQvR7"
      },

Here is what I get for the field pdName with either version: latest or 1.6.2

"pdName": {
        "createdAt": {
          "__type": "Date",
          "iso": "2015-10-01T01:54:43.289Z"
        },
        "de": "",
        "en": "Test name",
        "es": "",
        "fr": "",
        "it": "",
        "place": {
          "__type": "Pointer",
          "className": "Place",
          "objectId": "GrQzLeDfjh"
        }

It seems that latest is not pointing to 1.6.4 because I still have the same parent not defined error when using it, but when I change to 1.6.4 the relation error is not happening, but the query.include one yes.

I hope I made myself clear.
Thanks

@andrewimm
Copy link
Contributor

This might be an issue with caching on our cloud code servers. I'll kick off a cache flush and see if latest then points to 1.6.4 as it should.

@andrewimm
Copy link
Contributor

"latest" now appears as 1.6.4 for me. Check if you're still having issues, @marlonguerios

@a2
Copy link

a2 commented Oct 3, 2015

I can confirm that 1.6.2 works and 1.6.4 does not.

@marlonguerios
Copy link
Author

Same here. Now latest is pointing to 1.6.4, but I still have the problem with query.include not returning the included object.

@desamtralized
Copy link

Same issue here, my cloud code just stopped working, not included objects anymore :(
Changed to 1.6.2 and fixed.

@andrewimm
Copy link
Contributor

From my investigation, it seem that this only affects the results of queries made in cloud code (the query fetches the nested objects, they are available in cloud code, but when they return to the client they are pointers). Is that in line with what everyone here is experiencing?

@desamtralized
Copy link

@andrewimm same behavior here.

@andrewimm
Copy link
Contributor

Sorry all, I believe this was an oversight introduced in f2d35f2. We didn't realize this would affect nested queries coming back from cloud code, but we should have a fix in later today.

In the meantime, we've added tests for returning nested query results to our Cloud Code suite, so that we'll notice beforehand if something here breaks again.

@wangmengyan95 wangmengyan95 removed their assignment Oct 13, 2015
@wangmengyan95 wangmengyan95 added type:bug Impaired feature or lacking behavior that is likely assumed and removed needs investigation labels Oct 13, 2015
@andrewimm
Copy link
Contributor

1.6.6 fixes this. It's out on npm now, and is currently being deployed to cloud code. I'll follow up when that process has completed.

@andrewimm andrewimm mentioned this issue Oct 13, 2015
@andrewimm
Copy link
Contributor

This happened last night. 1.6.6 is available everywhere, and should fix this issue. "latest" on cloud code should also point to 1.6.6

@swilli40
Copy link

can you check this works with dotted dotted includes? e.g. x.y , myObject.createdUserRef

I am trying to get this to work and it works at the first level now, but doesn't seem to traverse

@swilli40
Copy link

is 'seen' in toJSON too simple? what about scenario where there are 2 pointers to the same object, but for different reasons and you want to expand 1. e,g,

"createdUserRef": {
"__type": "Pointer",
"className": "_User",
"objectId": "tUFQNVcQSD"
},
"userRef": {
"__type": "Pointer",
"className": "_User",
"objectId": "tUFQNVcQSD"
},

here the createdBy user and the user are different things that happen to point to the same _User

@andrewimm
Copy link
Contributor

@swilli40, we tried passing seen to toJSON, but the two paths were decoupled just enough that it made the process difficult to do cleanly. I would like to generalize the idea that all special types know how to encode themselves, and that encode simply does the tree-crawling, but it's going to take a little more time to clean up. You can consider 1.6.6/.7 as immediate responses to most people encountering this problem, while we buy ourselves a few more days to get a cleaner solution under the hood. I'm actively working on this.

@andrewimm
Copy link
Contributor

@swilli40 actually, I take that back. It looks like the original attempts were complicated by the same issue I hit with the eventually-merged solution: the exported version of encode did not take a seen-array as an argument. I've rewritten the solution, and once I've verified it works with multiple nested includes, I'll get it out to cloud code.

@swilli40
Copy link

It might need a leaf first crawler as converting a parse object to object means lower objects with attributes won't be expanded. Bottom up would prevent this issue.

@swilli40
Copy link

any news on this one?

@andrewimm
Copy link
Contributor

This should have been fixed in 1.6.8, which is currently on npm and will go out to cloud code later today

@swilli40
Copy link

great. thanks

@swilli40
Copy link

swilli40 commented Nov 1, 2015

Andrew, not fixed, built the 1.6.8 and debugged locally. Same issue with dotted includes. x.y
Parse REST interface expands, but _toFullJSON(), toJSON() converts to Pointer objects, even if include is specified and the returned JSON is expanded from Parse

@mbruschi
Copy link

mbruschi commented Jul 8, 2016

Hey, I'm experiencing the same issue in 1.9.

  var query = new Parse.Query('TimeEntry');
  var date = request.param.date;

  date.setHours(0, 0, 0, 0);
  query.greaterThanOrEqualTo('endDate', date);

  date.setHours(23, 59, 59, 999);
  query.lessThanOrEqualTo('startDate', date);

  query.ascending('startDate');

  query.include('project');

However the result does not include e.g. the project title or the color (both String).

[Object]
0:Object
  endDate: Fri Jul 08 2016 10:48:53 GMT+0200 (CEST)
  project: ParseObject
    _objCount: 4
    attributes: (...)
    className: "Project"
    createdAt: (...)
    id: "Si2r48jM1O"
    updatedAt: (...)
    __proto__: Object
  startDate: Fri Jul 08 2016 10:42:04 GMT+0200 (CEST)
...

I even tried to extend the Parse.Object like this and call the query correspondingly but with no result, except that the 'project' becomes a ParseSubclassObject.

var TimeEntry = Parse.Object.extend('TimeEntry');
var Project = Parse.Object.extend('Project');
var query = Parse.Query(TimeEntry);

What else can I do?

@andrewimm
Copy link
Contributor

@mbruschi the attributes object there contains your properties. Printing an object with console.log does not show attributes, since they are a) noisy and b) generated on demand from any local unsaved changes.

The fact that project is not a pointer, but a full-blown object with createdAt and updatedAt fields suggests that the include worked exactly as intended.

@adefokun
Copy link

adefokun commented Jan 15, 2017

But m having the same issue with 1.9.2 included key shows fully in network response but
get('includedKey').get('property') fails.

@aacassandra
Copy link

the same issue in 2.4.0
this is my code

  return new Promise((resolve, reject) => {
    // const Class = Parse.Object.extend(CLASS);
    const query = new Parse.Query(CLASS);
    query.include([
      "billboard",
      "billboard.complaintStatus",
      "billboard.taxStatus"
    ]);
    query.equalTo(OBJECT, KEY);
    query.find().then(
      res => {
        resolve(res);
      },
      err => {
        reject(err);
      }
    );
  });

billboard is a column name (pointer)
somebody help me? thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Impaired feature or lacking behavior that is likely assumed
Projects
None yet
Development

No branches or pull requests