Open scriby opened 10 years ago
Well, the idea is to avoid data duplication and prevent handling id's directly. Besides, it would be complex to keep the relation object and id property synchronised.
I seems that a patch for this would require to redefine the relations attrAsReference
and attrAsReferenceToMany
builder methods, you can take a look at src/module/extended/builder-relations.js for more information about how do they work.
Ok, that's fine. This probably just deserves some mention in the docs so users know to expect the behavior.
Am I right that I can't set the relationshipId
once I turn it into a relationship? So if I want to create an object and associate it with an existing object on the server, I can't just set relationshipId
, but I need to create a $new
instance of that type?
It seems like I can't do Model.$build({ relationshipId: 1 })
either to setup the relationship...
Looks like Model.$buildRaw({ relationshipId: 1 })
does work...
I just got hit by the "disappearing" relationship key field again when converting existing code to a relationship. I'd much prefer if we just left the key in tact, even if it didn't update automatically when the relationship changed later.
I'll add this to the docs
I have an object setup with a relationship, let's call it
x
. The key for the field isxId
. I'm noticing that when creating the object, thexId
field is not present, but I can read the id fromx.id
.I have a case on my hands now where that behavior is not really desired. If I start with just the
xId
field, then later change it to be a relationship, all the code I've written against thexId
field breaks. I am working on porting some $resource models over to restmod and encountering this.I wasn't really sure what the reasoning was for removing the original key properties.