[fdo-internals] Updated FDO RFC 23 For Review

[Greg Boone]

That sounds like an implementation detail for the KingOracle provider, and something you would have to deal with if you chose to implement DescribeClasses, just as you had to deal with it when implementing DescribeSchema.

Greg

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

Translation is done via mapping which is generated when Describe Schema was executed.
At least that is how King.Oracle provider works.
For example there could be 2 tables with same name but in different Oracle schemas. They could  end up in same Fdo Schema with different names.

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:59 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Updated FDO RFC 23 For Review

But, isn't that exactly what happens in an FDO Select command which takes  class name? You have to translate that into a select on a table.

Thanks,
Orest.

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

Now provider takes db schema + db table name + posiblle user overrides and generates fdo schema name + class name.

To gain profit from new functionality provider would now need to know exactly how from fdo schema + class name to get db schema+table.
I am affraid that process is not exact.

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

How is that any different from the existing DescribeSchema command?

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

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 :)

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/2607db7c/attachment-0001.html