FatFractal customer forums



Author Topic: Unexpected (?) behaviour when defining a GRABBAG  (Read 1656 times)

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Unexpected (?) behaviour when defining a GRABBAG
« on: March 22, 2014, 06:12:05 PM »
Hi again

I've defined the following in my application.ffdl:

Code: [Select]
CREATE COLLECTION /Offer OBJECTTYPE Offer
CREATE OBJECTTYPE Area (centerLatitude NUMERIC, centerLongitude NUMERIC, displayDescription STRING, radius NUMERIC, offers GRABBAG /Offer, identifier STRING)
CREATE COLLECTION /Area

What I expect to see as a result is a datatype called Area which contains (amongst the other named things) a set of references to some Offer objects. I am rather surprised to find that what is created is an Area type with an element called 'offers' which is an NSSet (a direct representation, not a set of refs). Conversely, the Offer type has a set of references to Area objects.

I should note that in a previous ffdl that the definition was the other way round - the Offer objects contained the set of references to Area objects, so it matches what I'm currently seeing.

[Time passes, while drdaz7 attempts to test some stuff]

Now I'm really confused. It doesn't appear that the application.ffdl I'm using has immediate effect... is there some kind of delay? The ffef client informs me that my app is available, and it responds to requests just fine, but the type and collection definitions in my ffdl are not being followed. It seems more like a previously uploaded ffdl is being followed.

Once again, it would be great if you could shed some light on this.

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Unexpected (?) behaviour when defining a GRABBAG
« Reply #1 on: March 22, 2014, 06:44:41 PM »
This is a consequence of your client-side code not using grabBagAdd to maintain the "offers" field - instead the areas are just being serialized "inline".

This is exactly the problem that you will no longer have tomorrow morning :-)

drdaz7

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: Unexpected (?) behaviour when defining a GRABBAG
« Reply #2 on: March 23, 2014, 06:55:08 PM »
Hi there

Actually, the issue I wanted to describe here isn't related to the grabBag operations as such. It seems to be related to ffdl handling.

It seems that once I've defined a property as a GRABBAG in the ffdl that it always appears as one in the FatFractal Data Browser - even once the ffdl has changed and no longer lists it as such. In fact, even if the property is removed from the class entirely and DROP COLLECTION COMPLETELY is called on the collection, the definition of the property remains.

This isn't a show-stopping issue, but it has a funny smell.

EDIT:

This isn't limited to GRABBAGs. Unused columns in the Data Browser remain following a DROP COLLECTION COMPLETELY (when new data is added which doesn't contain the property).
« Last Edit: March 23, 2014, 07:40:30 PM by drdaz7 »

gkc

  • Administrator
  • *****
  • Posts: 375
    • View Profile
Re: Unexpected (?) behaviour when defining a GRABBAG
« Reply #3 on: March 23, 2014, 09:02:46 PM »
Ok there are two logical constructs
1) OBJECTTYPE
2) COLLECTION (which may contain objects with different OBJECTTYPEs)

To eliminate data, you can either delete it all, or drop completely
To fully redefine an OBJECTTYPE you need to
Drop OBJECTTYPE foo
Create OBJECTTYPE foo (the stuff you want)


 

Copyright © FatFractal customer forums