Support arbitrary mappings of Entity to remote bucket name

[mikejohnstn]

We used to have this capability for unit tests, but it was factored out, and it probably wasn't a great implementation anyway.

Sometimes the Simperium bucket name may not match the local Entity name. In these cases it should be possible to maintain a mapping between the local and remote names:

1. By adding a UserInfo entry to the Entity you want to map in the Core Data model (similar to spDisableSync); and/or
2. Maybe by passing in a NSDictionary to Simperium's start method with any mappings you want to override?

Concrete example: if a remote bucket name is "Notes" and the local Entity name is "Note" we need to maintain a mapping between the two.

@fredrocious mentioned we may also need some kind of multi-mapping support (a single Entity's attributes mapped to remote attributes that are spread across more than one bucket). A use case here might help.

[jleandroperez]

@mikejohnstn just pushed a commit that brings back bucketOverrides mechanism (With a couple slight changes!).

Few comments regarding the implementation:

1: UserInfo entry
Looks like a super nice idea, but the attribute itself must be defined in the data model, which takes off the table the possibility of mapping something dynamically, at runtime (without some hacking at least).

2: Updating the start method
Since this is not going to be the most common scenario (by that i mean: mapping the local entity with a different remote bucket), i believe it would be a good idea to have the override mechanism as an optional thing, instead of something you have to init with nil (in most of the use cases).

All in all, i believe your original implementation (bucketOverrides attribute in Simperium) was the simplest, cleanest, and more flexible approach. So i've followed your original solution (with a couple differences in the SPWebsocketInterface side).

Regarding the multiple entity mapping, agreed, a use case would be super helpful. I'll leave this ticket open so we can discuss that.

Thank you!

[chengfred]

Re: use case, a simple one we ran into was for the radio project. Specifically:

We wanted to be able to split up data for users among different blogs (your recordings for one blog should be distinct from another). Possible approaches:

• A natural approach may be a bucket per blog (runs into issue we are discussing, effectively sharded buckets)
• What we have suggested to people in the past is have one bucket, but split by user (different user per blog)

The problem with the second approach is that we would also like users to be real blog users, so given that requirement we can't split by user. Another way to do it then, is to have one bucket, but have the blog to which it belongs be an attribute of the model. It's then up to the application to handle that division appropriately.

I'm not sure if that will work for all use cases (to essentially have no split, but have the app handle it in their data model). There are some consequences to having a single bucket, bucket.all listeners must handle all data, etc. Sharded buckets may be easier to scale (up to a point since we cant have too many buckets either), depends on the data.

Anyways there is nothing pressing that needs this currently, just recording some thoughts in case it comes up again.

[prvnl]

Off topic, but I noticed the remark about spDisableSync. If I enter this key value in the UserInfo of my attribute, entity or relationship, this would not sync using Simperium. That would be great because for a new project I need to store the ID of an paired BLE device in Core Data but this ID is device specific an thus should not sync.

Is this an undocumented feature or did I just miss this?

Regards,

Patrick

[jleandroperez]

@prvnl yes! that's exactly how the spDisableSync attribute works. It's in the iOS docs (https://simperium.com/docs/ios/):

By default, all Core Data attributes for a given object will be tracked and updated by Simperium. To override this for a particular attribute, you can add spDisableSync as a key in the attribute's User Info with a value of 1.

Cheers

[prvnl]

Thanks @jleandroperez, for the confirmation!!

[jleandroperez]

@prvnl no problem Patrick!