FatFractal customer forums



Author Topic: Grabbags... do they really need to be explicit in code?  (Read 2771 times)

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Grabbags... do they really need to be explicit in code?
« on: March 20, 2014, 07:15:00 AM »
Hi there

I'm looking at the GRABBAG backend type, and it seems I need to use specific calls in my client code to add to and remove from them. Specifically grabBagAdd and grabBagRemove in Objective C.

I'm sure there's a great reason for this, but as a layman user of the product, it strikes me that I don't really need to or want to know about how FatFractal represents this data up in my client code. I've defined the collection properties which I want to map to the GRABBAG type on the backend, so the backend can already know that when it receives additions and removals from these collections, that the GRABBAG should be updated accordingly.

I'm mentioning this as one of the big selling points of your platform is the lack of code-level lock-in, which has generally been very well handled. But in order to keep my code completely clean here, I need to do some gymnastics to fence the grabBag related code in (to not have it muddy up the data bearing types which are passed around my app). A really clean implementation from my perspective would be to only have to add or remove objects from the native collection type I'm using (NSMutableSet, NSMutableArray, or whatever), while the FatFractal representation of these actions would happen automagically.

I suppose that a very naive implementation of this kind of this could result in some very chatty network activity... but perhaps this could be overcome somehow. Or, maybe there's a way of doing this in code which doesn't require the use of these methods explicitly, and I just haven't recognised them.

Anywho... just a thought.

jonnycools

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #1 on: March 20, 2014, 07:37:32 AM »
Fellow user,

The issue here is scalability. Grabbags are designed to scale to thousands of relationships. These are not type of things you keep synced to local arrays. You usually retrieve the entities of Grabbags in paginated queries. Upon first creating an object things are great as the array may represent the compete set, but for any other type of operation it may not. Say I update an object with a grabbag but I don't have any objects in the array at update, maybe I chose not to retrieved them as I didn't need it. Does the server assume that you intend to have an empty grabbag. What I can say is that similar data structures are handled like this on other comparable BaaS services. The explicit need to make these calls is important. It also the only true way to prevent the user from having a special object to maintain these Grabbags, that in my opinion is more lock in, although there are some advantages.

The only true way to keep your code clean would bs not to use he SDK and go REST. This is as good as it gets when trying to maintain that no data type lock in.

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #2 on: March 20, 2014, 08:33:09 AM »
Quote
These are not type of things you keep synced to local arrays.

Except the documentation and some posts in here inform that this is an entirely valid and supported use-case. I can't argue against the notion that there may be another intended purpose though.

Grabbags are of some interest to me since I am attempting to maintain to-many 2-way references in a similar way to what CoreData provides. This seems non-trivial, even using grabbags.

Quote
Say I update an object with a grabbag but I don't have any objects in the array at update, maybe I chose not to retrieved them as I didn't need it.

Sure. But the framework can be aware of whether you changed the elements in the array or not. Things do get a little hairy here admittedly.

Quote
The only true way to keep your code clean would bs not to use he SDK and go REST.

This wouldn't really be keeping my code clean, as much as opting to reimplement the functionality of the SDK myself :). Aside from grabbag functionality, I haven't noticed any functionality in FF that bleeds in this way. That said, I've only been playing with it for the past week or so.

EDIT:
Perhaps it would be helpful if I describe more precisely what I'm trying to achieve.

I'm trying to persist 2 objects, each one has a set of the other.

One is called Area:
Code: [Select]
@interface Area : NSObject
...
@property (nonatomic, retain) NSMutableSet *offers;
...
@end

The other is called Offer:
Code: [Select]
@interface Offer : NSObject
...
@property (nonatomic, retain) NSMutableSet *areas;
...
@end

Creating this relationship in code (by adding one object to the others container set, and then vice-versa) causes (perhaps unsurprisingly) an infinite loop in the SDK, followed shortly after by a crash.
« Last Edit: March 20, 2014, 08:48:47 AM by drdaz7 »

jonnycools

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #3 on: March 20, 2014, 09:21:33 AM »
Quote

Except the documentation and some posts in here inform that this is an entirely valid and supported use-case. I can't argue against the notion that there may be another intended purpose though.


What is your use case?

Quote

Grabbags are of some interest to me since I am attempting to maintain to-many 2-way references in a similar way to what CoreData provides. This seems non-trivial, even using grabbags.


Are you trying to maintain explicit two way references? Do you really need it? I ask because you can use BackReferences and Alias to take advantage of the platform's built in method of meaning two way relationships. The only caveat is you on one side of the relationship you won't know its there until you query for it.

Take a parent to child relationship. It is common to declare a reference from child to parent. When retrieving a child its trivial to see who their parent is. However asking the parent who are your children isn't explicitly defined. Here you can use backReferences to find its child easily even as the platform maintains two way relationships for you.

Code: [Select]

<parent>/<guid>/BackReferences.<ChildrenCollection>.<parentReference>


In a previous release they added the ability to have alias be populated with the object. so when using the depthGB= in queries all alias would be retrieved as well. So the thats one way of getting two way relationships handled for you. Of course this extend to Grabbags both ways as well.

I glossed over this, but if you need further explanation here just ask.

Quote

Sure. But the framework can be aware of whether you changed the elements in the array or not. Things do get a little hairy here admittedly.


Now that's interesting. More on this in a bit.

Quote

This wouldn't really be keeping my code clean, as much as opting to reimplement the functionality of the SDK myself :). Aside from grabbag functionality, I haven't noticed any functionality in FF that bleeds in this way. That said, I've only been playing with it for the past week or so.


Now there's a scary thought, one I have contemplated.

jonnycools

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #4 on: March 20, 2014, 09:32:07 AM »
Really I could see that creating a retain cycle but an infinite loop, really?

Quote

Sure. But the framework can be aware of whether you changed the elements in the array or not. Things do get a little hairy here admittedly.


To be honest I'm having problems with this one myself. After the initial creating of the objects. Sometimes its hard to say whats changed, when I don't commit changes right away.

The only thing is should and can the framework do this via an NSMutableArray or would you still have to make that separate call (Tracking the contents of arrays can be a lot of overhead). Removing things is where problems crop up, how do I know somethings was taken out if I don't know it was there to begin with.

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #5 on: March 20, 2014, 09:53:23 AM »
Quote
Really I could see that creating a retain cycle but an infinite loop, really?

I'm not quite sure of the exact nature of the madness induced... what I see is millions of lines of log being produced in a loop until the app crashes. I didn't investigate further than that :D

Quote
The only thing is should and can the framework do this via an NSMutableArray or would you still have to make that separate call (Tracking the contents of arrays can be a lot of overhead).

Again, I haven't thought this through (the infrastructure isn't my project, thankfully), but I would imagine using an observer pattern on the collections in question could allow the framework to maintain some awareness of changes.

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #6 on: March 20, 2014, 10:01:33 AM »
Oh wow... there were 2 answers :)

Quote
What is your use case?

I was referring to the idea of keeping a grabbag synced to a local collection. You said this wasn't their purpose.

My use case is described towards the bottom of the post you replied to. (After the EDIT:.)

Quote
Are you trying to maintain explicit two way references? Do you really need it?

Probably not, but I built this app around CoreData initially, and since finding FatFractal have attempted to strip the CD layer out and replace it with FF. I'd like to mess with the existing code as little as humanly possible... so yeah, I'm making great effort to be lazy.

But since starting this thread, I've started looking at the model in FF's terms more closely. I can certainly achieve what I'm looking for without the explicit 2 way references... the only question is how much of my existing code is going to break.

jonnycools

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #7 on: March 20, 2014, 10:36:56 AM »
Quote

I was referring to the idea of keeping a grabbag synced to a local collection. You said this wasn't their purpose.


Well fatfractal doesn't support arrays of references. Grabbags are supposed to serve that purpose. I will admit sometimes I wish they did. Right now Array are only for embedding the objects data directly in another object.

Keeping stuff synced is all up to you really. I'm finding that quite tiresome but it's just part of the job I suppose. I'm actually considering a hybrid coredata, ff mashup now.

Well I lean data molding the hard way. I swear I've remodeled my database like 20 times. It all depends on how you want to use it. It recommend modeling the relationships based on his you intend to use them rather that how they are inherently structured.

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #8 on: March 20, 2014, 10:58:33 AM »
Quote
Well fatfractal doesn't support arrays of references.

It certainly seems to!

I have no trouble creating an Offer object with a set of Area objects (including the metadata pointing to the ffUrl). Or vice-versa. The trouble here is that the reference from the objects in the set to the containing object is inaccessible.

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #9 on: March 20, 2014, 11:06:26 AM »
Quite a lot to digest here. Will reply in a while

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #10 on: March 20, 2014, 11:37:44 AM »
I'll keep this brief:

1) The grabBagAdd / grabBagRemove are there in order to support scalability to many many many related objects
2) However yes I agree it should be easy to handle grab-bags (sets or arrays of referred objects in your client model) without any special code.

I had concluded a few days ago that this was required. I have therefore been working on
a) a change to the server-side if supplied with an array of objects which have ffUrls, treats them as grab-bag entries
b) a change to the client-side so when serialising arrays or sets, if the objects in those arrays or sets have ffUrls, then to serialise only the ffUrls

It will continue to be the responsibility of the client code to ensure that the related objects have been persisted

This is all part of a release which we will be doing on Saturday

As for "save everything in this context that has changed" - this is doable but brings some additional complexity which I need to be careful with

- Gary

PS There is guard code against cyclic relationship recursion resulting in crash but it clearly isn't working in this case :-) Will reproduce and fix

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #11 on: March 20, 2014, 11:59:36 AM »
I think I love you, man.

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #12 on: March 20, 2014, 12:16:00 PM »
Let's not go crazy :-)

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #13 on: March 22, 2014, 03:22:10 PM »
Will there be an announcement somewhere when this new, all-singing, all-dancing release is out?

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Grabbags... do they really need to be explicit in code?
« Reply #14 on: March 22, 2014, 03:57:21 PM »
Yeah - in the final stages of testing the release now (integration tests complete, currently running performance and soak tests which should be finished in about 5 hours) after which will be releasing (if all is good)

 

Copyright © FatFractal customer forums