[fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By Index ... Updated

[Orest Halustchak]

Hi,

FDO RFC 34 has been updated as per comments below. See: http://trac.osgeo.org/fdo/wiki/FDORfc34

Additional statements have been included at the end of the RFC:

To make sure that the access by index is easy to use by client applications, this RFC is including an additional requirement on the indexing.

The index order supported by the feature reader must be the same as the order of the properties described by the class definition that is returned by the feature reader. This allows application developers to have a predictable ordering and not have to maintain additional mapping tables at their end.

The default feature reader implementation described above will follow this requirement. Providers that do not implement these new functions natively will not have to change for applications to be able to use the index access. For providers that implement these new functions natively, this index ordering requirement must be used.

Since the RFC has changed, we should re-start the voting on this.

+1 from me.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, September 16, 2009 3:21 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By Index


It's fine for me as well.

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Carsten Hess
Sent: Wednesday, September 16, 2009 3:10 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By Index

I think what Orest says makes sense both the requirements and the methods to go from and to. As far as I know this matches the ADO.Net readers then exactly (which is a good thing imo).

-- Carsten

P.S. By the way I noticed that I said the opposite than intended in my last reply to this thread  - I am glad you all corrected it by now.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Wednesday, September 16, 2009 3:04 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By Index

The current RFC includes a default implementation so that the new api can be used with providers that don't implement this natively or don't get to it right away. If the default implementation maintains the same index as per the class definition then we should be ok with providers that stay with this default.

So, for providers that choose to implement this api natively, we want to add the requirement that the index of properties will be the same as the order in the class definition. We should be able to add that requirement here. If we make that change, then the rest of the RFC would be acceptable?

I would still include the property to / from index functions, though.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, September 16, 2009 2:42 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By Index


I think the discussion keeps dancing around the issue without anybody giving an objective technical reason of why it is impossible for the order of the properties in the class definition returned by the Select to match the indices returned by GetPropertyIndex. If it is not impossible, then at least give some other overwhelming reason of why it should not be done.

The following arguments are not sufficient:

*         Existing providers should not have to be forced to change - as far as I know there are no existing providers implementing this new API which we are introducing with this RFC.

*         It's more work to do it like that - the same amount of work would have to be done on the client side in order to use this feature if it is not done on the provider side

Unless I am misunderstanding things, the default implementation will actually conform to this, since it will get the indices from the class definition. Providers which are unwilling to implement uniform indexing can simply fall back to the default implementation, which will automatically give them uniform indexing.

The GetClassDefinition call can build up the property collection in any way it wants. Is there anything stopping it from ordering the collection of properties based on values returned by GetPropertyIndex?

Traian




... The rest of the thread was snipped. ...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20090921/6b5781c9/attachment-0001.html