= FDO RFC 15 – FDO !PropertyValueConstraintDictionary Class =

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||February 9, 2008||
||Last Modified||Maksim Sestic [[Timestamp]]||
||Author||Maksim Sestic||
||RFC Status||Draft||
||Implementation Status ||Not Applicable||
||Proposed Milestone||3.3.1.0||
||Assigned PSC guide(s)||(when determined)||
||'''Voting History'''|| ||
||+1||||
||+0||||
||-0||||
||-1||||


== Overview ==

Presently, `PropertyValueConstraintList` may contain only plain list of predefined values forced upon particular `PropertyValue` (minus null value). In my opinion, it somehow beats sole purpose of Constraints in a view of overall datastore consolidation.

This RFC suggest enforcing sound ''rules'' for data types and saving lots of storage - it's not clever to keep underlying i.e. !RoadTypePropertyValue as String since it takes too much space, it's not possible to change associated meaning of data once the data is in the store, while schema user from different country may not understand ''by default'' what Main road means, etc.

On the client side, developers may build more robust UIs to deal with FDO-based data. I.e. a !ComboBox instead of plain text field, where combo has it's values set to predefined `PropertyValueConstraintDictionary` object range and displayed members consist of associated string values. In that way users will be able to pick between Highway, Main road or Street, while underlying datastore keeps it's `short` or `boolean` (or any other) universal representation.


== Motivation ==

There are two possible approaches to this:

  1. `PropertyValueConstraintDictionary` - a Constraint that will keep pairs of [object,string] values, where object is a key dictionary member (an item in present `!PropertyValueConstraintList`), while associated string represents localized description of the value itself. 

Example:

{{{
RoadTypePropertyValueConstraintDictionary:

null , "n/a"
0    , "Highway"
1    , "Main road"
2    , "Street"
...
}}}

This one is bit harder to implement. That's because present implementation of `DictionaryElement` (building block of `DictionaryElementCollection`, which, I guess, ressembles to generic FDO Dictionary) has following definition: 

{{{
OSGeo::FDO:Common:DictionaryElement (System::String *name, System::String *value) 
}}}

This is a bit tricky in the light of `PropertyValueConstraintDictionary` since dictionary key is a String, while `PropertyValue` may be of any (reasonable) FDO type for that matter. I guess it would take few additional generic dictionary elements with different Key types (Short... Int16, Int32... Double... etc). Term "name" used for `DictionaryElement` parameter is not appropriate - term "key" is somehow more suitable. It seems that !DictionaryElement and !DictionaryElementCollection classes may undergo major reconstruction for `PropertyValueConstraintDictionary` to work.

  2. `PropertyValueConstraintLookup` - a Constraint with it's definition based on data persisted in another class. Please see related proposed solution and implementation details below.


== Proposed Solution ==

Suggestion is to create new class named `PropertyValueConstraintLookup` (or `PropertyValueConstraintPickList`, as Barbara proposed) - a Constraint with it's definition based on data persisted in another class. Such Constraint would only reference another lookup class' contents - it's internal Dictionary would act as a proxy, meaning that no actual data would get associated with such Constraint.

Proposed class fits into `OSGeo::FDO::Schema` namespace, where `PropertyValueConstraintLookup` inherits `PropertyValueConstraint` just like `PropertyValueConstraintList` and `PropertyValueConstraintRange` do.

Functionality overview:
  1. new class !PropertyValueConstraintLookup (or !PropertyValueConstraintPickList)
  2. takes feature schema name as parameter
  3. takes a source class/feature class name from 2) as parameter
  4. takes Key property name from 3) for key data source
  5. takes Value property name from 3) for value data source (can be same as 4) for that matter)
  6. has a getter method returning... well... instantiated !FdoReader instead of a dictionary (?)
  7. has !GroupBy and !SortBy optional properties being cast upon 3)
  8. Throws an error if there're duplicate keys in 4) - acting as some sort of proxy dictionary

There's also one tricky thing about such class - it's "persistancy" within feature store when underlying data changes (4,5). In other words - it doesn't represent a true constraint. Otherwise, it would probably make it all too complex and resource-consuming to implement. For starters, let's have a consumer developer keep track of underlying data versioning and consistency.


== Introduced Pros ==

 * Major storage saver
 * Splits data value from data representation (0 = "Highway" or True = "Yes")
 * Enables creating of flags via binary math (1+2 = 3 = "Main road" AND "Street")
 * Resolves data Localization issues
 * Enables more advanced UI solutions on client side