[fdo-internals] Updated FDO RFC 23 For Review

[Haris Kurtagic]

What I see as potential problem is how provider will  figure out from
class name what table is that.

 

Haris

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Thursday, July 17, 2008 7:43 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

Yes, adding the feature class list to DescribeSchema would be more
compact but would only make sense if all the providers were updated to
support those. If we can get agreement from all the provider writers to
update their providers, then that would be a cleaner solution.

 

Thanks,

Orest.

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Thursday, July 17, 2008 1:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

Hi Traian,

 

The "crazy alternative" was explored in the original version of this
RFC.  The optional implementation of returning specific classes as well
as issues with giving feedback on whether the command will honour the
specifying of classes was not an acceptable solution.  

 

Ronnie

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian
Stanev
Sent: Thursday, July 17, 2008 11:10 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

 

OK I see. In that case, I'd prefer the breaking change in DescribeSchema
(where you can ask for specific classes). It's true that we have to
update all providers, but IMO keeps the API more compact. 

 

A crazy alternative would be to add a function to the DescribeSchema
command which lets someone specify feature class names they are
interested in. This can then be treated as a hint by the providers which
need that and other providers can ignore it and return the full schema -
either way the class that the caller cares about will be in the returned
schema. This way there would be no work required of provides that don't
need it, and there are no new commands or capabilities to add.

 

Traian

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Brent
Robinson
Sent: Thursday, July 17, 2008 12:58 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

Hi Traian,

 

It would be the last case. The RDBMS providers cache the schemas but the
first time retrieval can be expensive when there are many classes.

 

Brent. 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian
Stanev
Sent: Thursday, July 17, 2008 12:53 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

 

The impact on non-RDBMS providers like SDF is a bit unclear to me. It
seems like there are two cases.

 

(1)    FDO connection is kept open. In such case DescribeSchema
operation is free, since the schema is cached internally by the
connection.

(2)    FDO connection is opened and then those new commands are executed
- in this case the schema would have to be deserialized, in its
entirety, which would not make the new commands perform any faster than
DescribeSchema.

 

It seems to me like making the RDBMS providers cache their schema
internally is something that would make the extra commands unnecessary,
and would only limit code changes to providers which do have a problem
with DescribeSchema, instead of having either all providers implement
new commands, or having client code have two code paths everywhere it
deals with getting a schema. However, I do not know enough about the
RDBMS providers to be sure if caching the schema is not possible in
their case. Or are we talking about the case where getting the schema
even once, to cache it, is too expensive (like if there are 1 million
classes in Oracle)?

 

 

Traian

 

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, July 17, 2008 12:41 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

 

I like this approach, though for consistency it would be nice if all of
the providers implemented these new commands as soon as possible.  

 

>From my perspective, having to special case everything based on
capabilities can get a bit frustrating, especially for lowly scripters
who barely understand how to tie their shoes J

 

Jason

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Thursday, July 17, 2008 00:39
To: FDO Internals Mail List
Subject: [fdo-internals] Updated FDO RFC 23 For Review

 

RFC 23 (http://trac.osgeo.org/fdo/wiki/FDORfc23) has been updated and
re-posted for review.   In particular, the previously proposed changes
to DescribeSchema have been dropped, and replaced with a new
DescribeClasses command.  Also the API command names for enumerating
schemas and classes have been updated to GetSchemaNames and
GetClassNames.

 

Please review the new proposal and reply to this list by July 23.  

 

Thanks

Ronnie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080717/84030cfb/attachment.html