-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Add support for polymorphic relationships #234
Comments
Nice work here. Can you post the |
@charlesfries here is the link to the |
This comment was marked as outdated.
This comment was marked as outdated.
Thanks for bringing this up. I've never used the At the moment, I'm unable to work much on the project because my focus is somewhere else, and if ever I start picking up work on this again, my priority is to address #229 on which I have some WIP already in this branch. Would be happy to take a PR for this if anyone wants to try. |
Think I figured it out. Just needed to explicitly defer to |
Copy-paste from original comment I've been looking into this and my conclusion here is I don't want to implement a default way to handle polymorphism. What I'm looking into is if I can provide some overridable API in the serializer that can be used to setup polymorphism. But to be honest, I don't think that it's a good idea to use polymorphism even if the adapter is capable of doing it especially for large scale apps, let me explain. In order for polymorphism to work, your data needs to have some indicator on what type of model this would be. It can look like this: {
"id": "farm_1",
"animals": [
{ "id": "pet_1", "type": "sheep" },
{ "id": "pet_2", "type": "cow" },
{ "id": "pet_3", "type": "cow" },
{ "id": "pet_4", "type": "chicken" },
]
} The example above is for a has-many polymorphism. Imagine if you have that as a Granted that some may force their way into using polymorphism especially if they can guarantee that the has-many relationship wouldn't grow in size, this is something that I will try to look into. As mentioned above, the approach that I'd like to take is to provide APIs that developers will override in order to setup polymorphism based on how they structure the data in their Firestore project. EDIT: Actually, it seems that Ember Data is capable for determining async polymorphic. Meaning, you can determine the polymorphic type after doing the actual fetching. This should provide a better and more natural integration with Firestore as I build the APIs. |
Should #236 be revisited because of your edit comment? |
I'll be honest that my last comment here has been more than a year already. I can't recall if something prevented me from working on the feature and I should've commented it if there was any. I don't have a timeline on when I can revisit this. |
With use of
polymorphic: true
in a (Ember Data) model relationship we need support in the serializerHere is a solution we put in our app:
The text was updated successfully, but these errors were encountered: