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

hasMany relationship not saved unless serializer present #160

Open
dale42 opened this issue Nov 12, 2016 · 5 comments
Open

hasMany relationship not saved unless serializer present #160

dale42 opened this issue Nov 12, 2016 · 5 comments

Comments

@dale42
Copy link

dale42 commented Nov 12, 2016

I encountered what I believe is the same problem as @asuraphel in #143 (Bidirectional hasMany relationship has empty list on the many side).

The hasMany relationship was not being saved into PouchDB, though the updates were being displayed properly in the templates until the browser was refreshed or restarted. Adding a serializer resolved my problem, as it did @asuraphel's.

I'm filing this issue because I think there is still an outstanding question:

  • Is this issue caused by version differences that require a serializer in some configurations and not others?
  • Is this issue caused by the serializer requirement not being documented in the README.md?

In case this an issue caused by configuration differences, I've made my test app available so you can see my configuration: https://github.com/dale42/pouch-serializer-demo And also, perhaps, in case I did something else completely left-field :)

If this is simply an undocumented requirement then the README.md should be updated.

Issue #117 (Install serialiser by default?) may also be related.

@broerse
Copy link
Collaborator

broerse commented Nov 13, 2016

I like to merge #159 that removes the need to store the hasmany side. If the hasmany is stored and synced by multiple users first strange errors occur. @nolanlawson has to find time to merge PR pouchdb-community/relational-pouch#61 first. @dale42 perhaps you can try if PR #159 works for you.

@broerse
Copy link
Collaborator

broerse commented Nov 28, 2016

@dale42 FYI I merged #159

@chrisortman
Copy link

I am trying this out and it seems like with this change I am able to get things to save, but I have to call save on the child object? And if I call save on the parent object it does not cascade down?

in my add child action I create a new child record and give it the parent then save it and it is added to the parents document ... but if I call save on the parent instead it puts a null into the child array

I also would expect that after I get the child added to the parent and then change a property on the child I should be able to call save on the parent record and it would save the changes but it does not

@jlami
Copy link
Collaborator

jlami commented Dec 2, 2016

@chrisortman, I don't know if you are using the new dontsave option? This means ember-pouch works like a normal ember-data adapter. And as far as I know a parent save never saves properties of children.
If you are using the default options of ember-pouch you might want to checkout the readme, specifically the saving child ids part.

Look at https://guides.emberjs.com/v2.10.0/models/relationships/#toc_creating-records for an example of the normal ember-data way.
They also mention a scenario that looks more like the thing you're saying:

We could have also linked the two records together by updating the blogPost's hasMany relationship:

blogPost.get('comments').pushObject(comment);
comment.save().then(function () {
  blogPost.save();
});

But I believe that the comment.save() is actually the required part. This will save the relationship on the child side. The blogPost.save() part does not really do anything, or it should also have been required in the first scenario.

@broerse
Copy link
Collaborator

broerse commented May 26, 2017

@chrisortman @dale42 Did you get it working with the ENV.emberpouch.dontsavehasmany enabled?

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

No branches or pull requests

4 participants