ruby-hyperloop
Make has_many through writeable
In Rails, has_many through: (and has_and_belongs_to_many) is writeable if Rails can infer inverse_of or you specify it explicitly.
Currently Hyperloop explicitly doesn't save to through:s (note the [email protected]_association?)
https://github.com/ruby-hyperloop/hyper-mesh/blob/ebf661eecc592799b7723bb666c1d42d84551918/lib/reactive_record/active_record/reactive_record/collection.rb#L352
Relevant bits of Rails docs (search for has_many):
Has Many associations can be configured with the :through option to use an explicit join model to retrieve the data. This operates similarly to a has_and_belongs_to_many association. The advantage is that you're able to add validations, callbacks, and extra attributes on the join model.
If the association on the join model is a belongs_to, the collection can be modified and the records on the :through model will be automatically created and removed as appropriate. Otherwise, the collection is read-only, so you should manipulate the :through association directly.
If you are going to modify the association (rather than just read from it), then it is a good idea to set the :inverse_of option on the source association on the join model. This allows associated records to be built which will automatically create the appropriate join model records when they are saved.
If you are using a belongs_to on the join model, it is a good idea to set the :inverse_of option on the belongs_to
If you do not set the :inverse_of record, the association will do its best to match itself up with the correct inverse. Automatic inverse detection only works on has_many, has_one, and belongs_to associations.
I expect it'll be a bunch of work to get it working though. Especially in such a way that it will also work with HABTM as the join model can't be saved directly as it won't exist on the server in the HABTM case, so the current Hyper Mesh API may not even support it. Perhaps it could be done as a server method or operation.
I think this is related to a bug just discovered. See https://github.com/ruby-hyperloop/hyper-mesh/blob/ebf661eecc592799b7723bb666c1d42d84551918/spec/batch3/many_to_many_spec.rb#L43
What happens in this spec if you watch in the debugger is that the Commenter structure on the client is never updated. Rather the system gets confused and attempts to update the User record's todo_item field. Which does not exist. In current master and edge up to lap27 this writing to the bogus attribute (todo_item) on the user record is ignored (with a warning in recent laps)
What should happen is that the Comment record on the client is updated. Not quite sure how to do this within the current structure.
At any rate I suspect fixing this "side" issue, will fix the whole thing. For now the related test_spec has been marked pending.
