[fdo-internals] RFC15 posted

Maksim Sestic max at geoinova.com
Fri Mar 14 07:51:22 EDT 2008


Hi Orest,

I updated RFC15 to reflect latest forum discussions. If it's going to go
down the Dictionary road I don't have enough knowledge of it's internal
mechanisms and potential changes that might cause major redesign of
Dictionary class.

Regards,
Maksim Sestic



Orest Halustchak wrote:
> 
> Hi Maksim,
> 
> We had an FDO PSC meeting yesterday and were wondering about the status of
> this. It wasn't meant to rush you.
> 
> Fdo-internals is a good place to discuss ideas. Since you have the RFC
> document started already, I would just update that document as the ideas
> are solidified.
> 
> Thanks,
> Orest.
> 
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: Thursday, March 13, 2008 9:06 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] RFC15 posted
> 
> Feel free to write the interface definition in whichever language you feel
> comfortable with. I can translate it to C++ after the fact.
> 
> Regards,
> 
> Greg
> 
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Thursday, March 13, 2008 3:29 AM
> To: fdo-internals at lists.osgeo.org
> Subject: RE: [fdo-internals] RFC15 posted
> 
> 
> Hi Orest,
> 
> I didn't had time to update the RFC with latest forum ramblings :-) but I
> promise to do that either today or tomorrow. Is RFC the right place to
> discuss about PropertyValueConstraintLookup, or should this rather go
> through Futures Wiki? I'm not skilled in writing C++ interface
> definitions.
> 
> Regards,
> Maksim Sestic
> 
> 
> 
> Orest Halustchak wrote:
>>
>> Hi Maksim,
>>
>> I was wondering if you have been working on this and if you were planning
>> to make changes to the posted RFC document?
>>
>> Thanks,
>> Orest.
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org
>> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
>> Sent: Thursday, February 14, 2008 5:17 AM
>> To: fdo-internals at lists.osgeo.org
>> Subject: RE: [fdo-internals] RFC15 posted
>>
>>
>> Hi Orest,
>>
>> Yes, that's another possibility (and much more elegent I guess). It also
>> resolves dictionary "refreshing", meaning - what and when triggers data
>> re-fetching upon dictionary elements collection.
>>
>> Let's see how it might work:
>>
>> 1) new class PropertyValueConstraintLookup (or
>> PropertyValueConstraintPickList, as Barbara proposed)
>> 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.
>>
>> Regards,
>> Maksim Sestic
>>
>>
>>
>> Orest Halustchak wrote:
>>>
>>> That's a good point about DictionaryElement, but before we dive into
>>> that
>>> one, I'm wondering about whether it would be used at all to define the
>>> constraint. If the constraint is defined based on data persisted in
>>> another class, don't we need just references to that other class and not
>>> an actual dictionary held in a structure in memory? Or ... are you
>>> thinking that the constraint can defined either way, an explicit
>>> dictionary attached to the property definition or a referenced
>>> dictionary
>>> in another class? Do we need both?
>>>
>>> Thanks,
>>> Orest.
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/RFC15-posted-tp15408616s18162p15477115.html
>> Sent from the fdo-internals mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>
>>
> 
> --
> View this message in context:
> http://www.nabble.com/RFC15-posted-tp15408616s18162p16022478.html
> Sent from the fdo-internals mailing list archive at Nabble.com.
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> 
> 

-- 
View this message in context: http://www.nabble.com/RFC15-posted-tp15408616s18162p16048056.html
Sent from the fdo-internals mailing list archive at Nabble.com.



More information about the fdo-internals mailing list