[fdo-internals] RFC15 posted

[Greg Boone]

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