how does parse_strategy :sync work?

[Josh Cohen]

I've got a model for People and Addresses.  People have many addresses.

In my PersonRepresenter, I've got:

  collection :addresses, :class => Address, :extend => AddressRepresenter, :embedded => true , :parse_strategy => :sync

I initially stumbled upon the sync thing because I noticed that if I did a POST of a person, but didn't include the _embedded address array, it would delete my existing address collection for a given person.

Note, I'm doing some matching on POSTs.  If you do a post of a person and the server finds that a matching person already exists then it passes the existing person object to the consume! call in the person controller.

Is there a way I can:

1) If a collection property is not present in the request to the server, then leave the collection alone.  Dont get rid of it.

2) control how parse_strategy does its matching?  How does it know which record it is supposed to be updating?

--

Josh Cohen | @joshco | linkedin.com/in/joshrcohen | github.com/joshco

[Nick Sutterer]

Hey Josh,

the new option parse_strategy: :sync is pretty dumb: Instead of automatically creating new Address instances for the :addresses collection, it uses the instances and syncs their properties.

However, this only works when the parsed document contains the exact same number of addresses than the object #from_json is being called onto.

What we need to do is provide some more "cleverer" strategies which find out which object is an existing object and which one should be created. These strategies could provide some standard semantics for handling PUTs and POSTs in classic Rails apps.

Should we try to identify the strategies in a github issue?

--
You received this message because you are subscribed to the Google Groups "Roar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to roar-talk+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Josh Cohen]

Sounds good.  New issue created and populated from this thread.

 

One valuable strategy could be where

1) The server individually matches up representations in incoming request body for embedded resources with existing resources on the server

2) The matching algorithm is likely to be specific to a given API in terms of what fields constitute a match or not. Therefore, the matching method is provided to roar as some sort of callback ( proc, labmda, inheritance etc)

 

https://github.com/apotonick/roar/issues/85

 

Josh Cohen | @joshco | linkedin.com/in/joshrcohen | github.com/joshco