= FDO RFC 7 - Add New Methods to !FdoClassDefinition =

This page contains a request for comments document (RFC) for the FDO Open Source project.  
More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.

== Status ==
 
||RFC Template Version||(1.0)|| 
||Submission Date||July 25, 2007||
||Last Modified|| Barbara Zoladek [[Timestamp]]||
||Author|| Barbara Zoladek||
||RFC Status||draft ||
||Implementation Status|| under development||
||Proposed Milestone|| ||
||Assigned PSC guide(s)|| Greg Boone||
||'''Voting History'''||||
|| ||Bob, Mateusz||
|| ||Frank||
|| ||Orest||
|| ||Greg ||
 
== Overview ==

The purpose of this RFC is to enhance the !FdoClassDefinition class by adding new methods !GetIsVirtual() and !SetIsVirtual().


== Motivation ==

The motivation for this RFC is to expose classes based on virtual objects. The significat differenece between classes based on real and virtual objects is that the later do not contain any data themselves. Also, a virtual object is not stored in the datastore as a distinct object. An RDBMS view is one exmaple of the virtual object. It is just a named query. An FDO class based on that query exposes data that is contained in other objects referenced in the query. The class schema characterists like property types and constraints tightly depends on the these objects. Data exposed by the class is more dynamic as it can be edited or deleted from the objects that contain it. 

How these classes can be used? Classes based on virtual objects can be used for limiting or restricting access to some data and for analysis where a class exposes data that is combination of many classes joined in certain way with sometimes complex conditions.

Why is it important to distinguish these classes in FDO? Because these classes fall into a different category, for the same reasons why in RDBMSs views are distinguished from tables. These classes virtualness cannot be expressed by any existing methods of !FdoClassdefinition. In fact, their characteristics are somewhat unpredictable and depend on the underlying virtual object definition.
Exposing the virtual class type as a new type returned by !GetClassType() would affect current behaviour of existing applications.

== Proposed Solution ==

The following shows the proposed changes to !FdoClassDefinition:

{{{
     class FdoClassDefinition : public FdoSchemaElement
     {
        ...
        public:
            ...
            /// \brief
            /// Gets the value of m_IsVirtual. It is true if a class is based on virtual object; otherwise is false.
            /// 
            /// \return
            /// Returns bool
            /// 
	        FDO_API bool GetIsVirtual();

	    /// \brief
            /// Sets the value of m_IsVirtual. It is true if a class is based on virtual object; otherwise is false.
            /// This is an internal method that can only be called by providers. Application should not use this method.
            /// 
            /// \return
            /// Returns nothing
            /// 
	        FDO_API void SetIsVirtual( bool value );
            ...
        
         private:
            ...
            FdoBoolean	m_isVirtual;
            ...
       }

}}}

Note that for the providers where the virtual object concept cannot be used, GetISVirtual() will always return ''false''.

== Implications ==

This change will not cause any functional or performance side effects.

== Test Plan ==

Exisitng unit tests will be enhanced.