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

Save returns objects different from what they are into the database #457

Closed
Kira2 opened this issue Feb 17, 2016 · 7 comments
Closed

Save returns objects different from what they are into the database #457

Kira2 opened this issue Feb 17, 2016 · 7 comments
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@Kira2
Copy link
Contributor

Kira2 commented Feb 17, 2016

Hi,

I have a very strange behavior when I save an object, and that I apply a beforeSave trigger on it.

We suppose we have an object with an attribute equal to "100". We also have a "beforeSave" trigger that modifies this value to "50", if some conditions are right.

Now, when I call object.save(), the "beforeSave" is triggered, the value into the database is "50", but the value returned by the "save" operation is still "100".

How is it possible that the "save" operation returns an object with attributes different from what they are into the database?

Thank you.

@Kira2
Copy link
Contributor Author

Kira2 commented Feb 25, 2016

Maybe it is related to #653

@simonbengtsson
Copy link
Contributor

Have you tried this with the latest version of parse-server? There were some updates to the beforeSave triggers recently.

@Kira2
Copy link
Contributor Author

Kira2 commented Feb 25, 2016

Sorry, I forgot to mention that I already use the last version of parse-server.

@simonbengtsson
Copy link
Contributor

I'm seeing the same issue. Anytime a value is changed in a beforeSave trigger it is not set on the object passed as a result of the save promise. However the change is set correctly in the database. Here is a minimal example:

Parse.Cloud.beforeSave('Person', function(req, res) {
    res.object.set('name', 'Anton');
    res.success();
});

// Expected behavior is that Anton is printed both times, but William is printed at first 
Parse.Cloud.define('changeName', function (req, res) {
    var obj = new Parse.Object('Person');
    obj.save({name: 'William'}).then(function(obj) {
        console.log('From save method: ' + obj.get('name')); // From save method: William
        return new Parse.Query('Person').get(obj.id);
    }).then(function(obj) {
        console.log('From database: ' + obj.get('name')); // From database: Anton
        res.success();
    });
});

@gfosco gfosco added the type:bug Impaired feature or lacking behavior that is likely assumed label Mar 1, 2016
@gfosco
Copy link
Contributor

gfosco commented Mar 6, 2016

Verified this by creating a test inside specs/ParseAPI.spec.js:

  it('beforeSave change propagates through the save response', (done) => {
    Parse.Cloud.beforeSave('ChangingObject', function(request, response) {
      request.object.set('foo', 'baz');
      response.success();
    });
    let obj = new Parse.Object('ChangingObject');
    obj.save({ foo: 'bar' }).then((objAgain) => {
      expect(objAgain.get('foo')).toEqual('baz');
      Parse.Cloud._removeHook("Triggers", "beforeSave", "ChangingObject");
      done();
    }, (e) => {
      Parse.Cloud._removeHook("Triggers", "beforeSave", "ChangingObject");
      fail('Should not have failed to save.');
      done();
    });
  });

Working on a solution, will send a PR.

@gfosco gfosco added type:bug Impaired feature or lacking behavior that is likely assumed and removed type:bug Impaired feature or lacking behavior that is likely assumed labels Mar 6, 2016
@gfosco
Copy link
Contributor

gfosco commented Mar 6, 2016

We'll fix this with #865 😄

@gfosco gfosco closed this as completed Mar 6, 2016
@Kira2
Copy link
Contributor Author

Kira2 commented Mar 11, 2016

After upgrading to parse-server 2.1.5, it works again. Thanks for the fix.

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

4 participants