MOTION: FDO RFC 34 - FDO Reader Access By Index ... Updated - Adopted
|
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi, This motion has been adopted. Thanks everyone who provided feedback and suggestions. Regards, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev It’s fine for me as well. Traian From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Carsten Hess 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Traian Stanev 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. … _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
