Exclusive Collections

[ConvertFromOldNGs]

by Mike May >> Thu, 20 Jul 2006 10:47:00 GMT

Hi All,

Can someone tell me everything I need to know about exclusive collections? A bit of a broad question, I know, but all I've been able to glean from the docs and my own, limited, experience is the following:

(1) They don't take up any storage in the class instance itself, so no reorgs are required when adding or deleting them.
(2) They are implicitly present in the class instance, ie, they are created and deleted when the class is instantiated and destroyed.
(3) When I create a relational view, I can create additional tables corresponding to the exclusive collections on each class?
(4) If a collection isn't exclusive, then it's referred to as a 'shared' collection.
(5) If I change a collection from exclusive to shared, the shared collection will be added to the class and populated from the exclusive collection. If I change a shared collection to an exclusive collection, I ned to populate it myself. Both changes will require a reorg.

What I need to know is, what are the implications of using an exclusive collection, in terms of what I can and can't, and must and mustn't, do with it compared with a shared collection? Given that the check box for Exclusive is unchecked by default, I susect that at least one of those implications is pretty earth-shattering. In the unlikely event that everything I've said above is the be-all and end-all of exclusive collections, then what's the point of them?

Any help, advice and information will be gratefully received.

Regards,
Mike

[ConvertFromOldNGs]

by Brendan Doolan >> Thu, 20 Jul 2006 16:42:14 GMT

Hi Mike,
You've got most of the main points. Is 3 a question or a typo? I've never actually tried 5. Also, I thought that the checkbox is checked, not unchecked, by default when the type is changed to a collection.

I would also add

6) There is an optimisation that an exclusive collection is instantiated when it is first added to. usually this will pass without being noticed. However, if you put an update notification on the exclusive collection to trap new objects being added to it, you will miss the first object being added since a create, not an update notification will be sent due to the optimisation. This is detoured by using the "instantiate" method in the constructor of the parent object but definitely a trap for beginners.

7) You can't save the reference for the exclusive collection as a property value on an object. Equally you can't add it to a collection. To get round this you sometimes have to convert the reference to a string to save it and then back again when you need it, or alternatively save an iterator on the collection and use iter.getCollection to get it back again. You can pass them as parameters and return values and assign them to variables in methods.

8) If you do an instances (via code or from the IDE) on the collection type you pick up only shared collections.

9) Finally and most importantly, the main point of them is that they are the only way to define a 1 - many or many - many relationship. If you try to define a 1 - many relationship where the many side is a shared collection, it will in fact be a 1 - 1 relationship.

In practice usually point 2 is the main one people need to be aware of although many people don't give even that one a second thought. 6 and 7 can bite you if you aren't careful. 9 can catch out people who inadvertently uncheck the checkbox. There used to be a bug where if you changed the class type to a non-collection and then back to a collection type, the checkbox wouldn't get re-checked. So your 1 - many relationship was just 1 - 1. Fortunately this has been fixed.

Cheers, Brendan

[ConvertFromOldNGs]

by Michael J >> Fri, 21 Jul 2006 0:24:21 GMT

// (1) They don't take up any storage in the class instance itself, so no // reorgs are required when adding or deleting them.

Your wording is a little confusing here. so bear with me

-If you mean adding objects (instances) to the collection then no, a reorg is not required but adding/deleting items never causes a reorg anyway.

-If you mean adding an exclusive collection to a class or removing one, then yes a reorg most certainly is required. Exclusive collections can either be stored in the parent classes map file or in there own map. In both cases however a reference to the exclusive collection is stored in each instance of the parent class. So adding an exclusive collection does infact alter the data stored for each parent object thus requiring a reorg.

[ConvertFromOldNGs]

by Dr J >> Mon, 24 Jul 2006 2:35:24 GMT

"If you mean adding an exclusive collection to a class or removing one, then yes a reorg most certainly is required. Exclusive collections can either be stored in the parent classes map file or in there own map. In both cases however a reference to the exclusive collection is stored in each instance of the parent class. So adding an exclusive collection does infact alter the data stored for each parent object thus requiring a reorg."

It's probably worth noting that the parent object only requires additional space for the exclusive references each time you exceed a multiple of 8 exclusive collection references.

Suppose the class currently has 1 exclusive reference and the certify.log reports that instances of that class require 46 bytes. You can add up to 7 more exclusive collections and the certify.log will still show that instances of that class require 46 bytes. Only when you add the 9th exclusive collection will the reorg need to allocate additional space for instances of that class to handle the additional collection (now uses 47 bytes). You can then add exclusive collections 10 through 16 and assuming no other changes were made the instances of that class will still only require the 47 bytes of storage.

In earlier versions of Jade you did not even have to reorg to add exclusive collections unless you crossed a "mod 8" boundary.

[ConvertFromOldNGs]

by allistar >> Mon, 24 Jul 2006 9:02:22 GMT

Indeed. I've known people to use this feature to introduce new properties without requiring a database reorganisation by adding a StringArray to a class to get a new String property. When the next upgrade cycle is done then the StringArray is removed in favour of String.

Allistar.