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

This fixes duplicate key issue #649 #668

Merged
merged 1 commit into from
Nov 5, 2014
Merged

This fixes duplicate key issue #649 #668

merged 1 commit into from
Nov 5, 2014

Conversation

BerkeleyTrue
Copy link
Contributor

change.rectify will call save without __persisted flag set.
This causes DAO to treat model as new instead of as
an existing model to update.

@slnode
Copy link

slnode commented Oct 21, 2014

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@bajtos
Copy link
Member

bajtos commented Oct 21, 2014

@slnode ok to test

@bajtos
Copy link
Member

bajtos commented Oct 21, 2014

Hi @BerkeleyTrue, thank you for submitting the patch. The solution looks too hacky to me, as it is using an internal juggler property. However, I don't know enough about the replication internals, I'll leave it up to @ritch to judge that.

@BerkeleyTrue
Copy link
Contributor Author

Agreed on the hacky-ness, but I could not find exactly where this flag is to be set. This got me thinking about how that flag is normally set. Turns out if you change line 415 in change.js

change = new Change(change);

to

change = new Change(change, { persisted: true });

This also works, but I don't know what else this would affect.

@bajtos
Copy link
Member

bajtos commented Oct 29, 2014

The new solution looks better to me. Please add a unit-test that fails without your patch and passes with your patch in place.

@bajtos
Copy link
Member

bajtos commented Oct 29, 2014

Two more thoughts:

This looks like a bug in the juggler to me. I would expect that new Change(change).save() does update instead of create. /cc @raymondfeng

I don't understand why we are creating a new change object in the first place, since we already have one. Is there any reason why the following should not work?

this.find(function(err, changes) {
  if (err) return cb(err);
  changes.forEach(function(change) {
    change.rectify();
  });
});

@BerkeleyTrue
Copy link
Contributor Author

Removed the instantiation line. All seems to work as expected. Are there test that need to be added?

@bajtos
Copy link
Member

bajtos commented Oct 30, 2014

Are there test that need to be added?

I am don't know if there is an easy way how to test your changes in isolation against in-memory database. We should ideally run the test suite against MongoDB, but that's out of scope of this PR.

Could you please squash the commits and update the commit message?

@bajtos
Copy link
Member

bajtos commented Oct 30, 2014

(Other than that, the patch LGTM.)

@BerkeleyTrue
Copy link
Contributor Author

Sorry, squash the commits? Not sure what that means.

@bajtos
Copy link
Member

bajtos commented Oct 31, 2014

@BerkeleyTrue run git rebase -i master and follow the instructions in the editor opened by git. Once done, run git push -f to rewrite the history on the server too. More details can be found here: http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Let me know if you need more help.

@desmondmorris
Copy link

+1 this patch does the trick

This PR removes the instantiation of a new change model
as models return from Change.find are already
instances of Change. This solves the duplicate Id issue #649
@BerkeleyTrue
Copy link
Contributor Author

That was fun. How does that look?

@bajtos
Copy link
Member

bajtos commented Nov 4, 2014

@BerkeleyTrue Much better :)

One more thing - I need you to sign our CLA, see https://cla.strongloop.com/agreements/strongloop/loopback.

@bajtos
Copy link
Member

bajtos commented Nov 4, 2014

@slnode ok to test

@bajtos bajtos assigned bajtos and unassigned ritch Nov 5, 2014
bajtos added a commit that referenced this pull request Nov 5, 2014
@bajtos bajtos merged commit d9a426c into strongloop:master Nov 5, 2014
@bajtos
Copy link
Member

bajtos commented Nov 5, 2014

Landed, thank you for the contribution!

@BerkeleyTrue
Copy link
Contributor Author

Woot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants