Re: Persistence containers (was Why all the different string types?)

Am 30.03.2006 um 05:50 schrieb Guy Rouillier:

> Ok, thank you Oliver and Jens for clarifying.  Some ideas are starting
> to gel:
>
> (1) Persistence should be a characteristic of a (persistence)  
> container,
> not of data types.  Ideally, we should be able to use simple data  
> types
> (int, float, boolean, String) and delegate to the container how to
> persist them and retrieve them.
>
> (2) If we use the concept of a generalized persistence container, then
> we can have any number of them.  We can have one at application  
> (global)
> scope, and one for *each* sandbox/instance/project/repository/local
> (pick the term you like.)  Each container should know how to  
> persist and
> populate itself.
>
> (3) Each individual setting that goes into a persistence container is
> just a simple data value of a defined data type.  It doesn't need  
> to be
> identified as being of scope global (kNoClass) or of scope instance
> (kAddSettings), nor does it need to be of a specialized persistence  
> data
> type like CPersistentBool.  It automatically becomes a persistent data
> value when it is added to a persistence container, and it becomes a
> persistent data value of a particular scope depending on *which*
> persistence container you put it in.  You can even have a data  
> value of
> the exact same name in two or more persistence containers.  That would
> be the norm, actually, since all sandbox containers would likely have
> the same set of data values.
>
> (4) To keep a persistence container generalized, the container itself
> should not have to understand that it is "higher" or "lower" in a
> persistence hierarchy than any other persistence container.  Each  
> should
> be self-contained.  If a hierarchy exists, that hierarchy should be
> established external to the persistence container (perhaps in a
> persistence hierarchy tree.)  That may be more than is necessary;
> perhaps we only have a 2-level hierarchy, local and global.

I generally agree with your concept here, although from a 'users'  
perspective (i.e. when 'using' the persistence containers), it may be  
simpler to have the hierarchy defined intrinsically, so you don't  
have to do things like:
	if ( sandboxSettings->GetIntegerValue("foo", fooValue) )
		globalSettings->GetIntegerValue("foo", fooValue);

If each persistence container could have a fallback persistence  
container, it could ask the fallback container if it doesn't find a  
value. In our case, the sandbox settings would be constructed with a  
pointer to the global settings container, i.e. if a value doesn't  
exist in the sandbox settings, the settings container will fallback  
to asking the global settings container. Theoretically, even the  
global settings container could have a fallback settings container,  
which contains hardwired defaults...

Does that make sense to you?

</jum>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/