SetOfPrefs.h

// SetOfPrefs.h
//
// Author David Barrett-Lennard
// (C)opyright Cedanet Pty Ltd 2009

@import "cxOperation.h"
@import "Ceda/cxPersistStore/xset.h"

namespace ceda
{
/*
Note that in the call to 

    mImplement_xset(Key,bool bDefine,bool bImplement,bool bExport,bool bKeyMayHavePrefs, bool bDeclareKeysReachable)

we use

    bKeyMayHavePrefs = true
    bDeclareKeysReachable = false 

The reason has to do with the DeltaReader.  When it reads the set of objects to create, it may easily
deserialise the initial state of an xset<pref> field within an object, and so perform insert() calls with pref
values which have the oid member initialised but not the in-memory pointer, and in fact attempting
to dereference the pref member can throw a dangling oid exception because the objects to be created
are sent in an arbitrary order.

What it means
-------------

Let's limit this discussion to xset<T>, and what should happen when inserting elements of type T.

Consider that T is a "sale contained value type" meaning there are no pointers within it. Then 
clearly T may contain prefs internally and so declare reachable should be called.

Let T be a pref.  If the pref already has an oid then no problem.  If it doesn't then we should
visit what's in it.

Interesting approach:  When visit prefs, don't cause objects to be brought into memory.  Can this be a
mode stored in the pref visitor?  That would be handy!
*/

@if (!CEDA_USE_BTREE_WITH_TYPEOPS)
{
    // Define but don't implement
    mImplement_xset(prefbase,true,false,true,true,false)

    template<typename T>
    struct xsetModelTraits<pref<T> >
    {
        typedef BPlusTree_6_prefbase_void_9_ BTree;
    };

    template<typename T>
    struct xsetModelTraits<cref<T> >
    {
        typedef BPlusTree_6_prefbase_void_9_ BTree;
    };
}

} // namespace ceda