[fdo-internals] Standardising FDO Schema's

[Zac Spitzer]

Sticking with your oracle example, what can be achieved in terms with
custom mappings in terms of "naming" which can't
be achieved within the database, transparently to fdo?

the main one which comes to mind is for making the same data in which now
resides in a postgis database appear to be the same data, but named, as it
used to be, when it was served thru the oracle provider?

z

On Sat, Aug 30, 2008 at 11:37 AM, Zac Spitzer <zac.spitzer at gmail.com> wrote:

> On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <robert.fortin at autodesk.com
> > wrote:
>
>> As Orest said, FDO represents the data in different layer Datastore,
>> Schema and Class. That's the rule.  That's the standard.
>
>
> but currently there is no standard implementation pattern! that's the
> problem!
>
>
>> The fact that some provider doesn't have/require schema doesn't mean we
>> don't need a generic schema representation in FDO.  It's up to the provider
>> to say what this schema is named and what it maps to (e.g. default or
>> something else). FDO doesn't impose rules around the name of the schema.
>
>
> which means every implementation can be different!
>
> just focussing on the DB side for a moment, should an app really care or
> need to know
> about which fdo provider and which database i am using? Isn't FDO meant to
> flatten out all
> these differences?
>
> I am just advocating adopting a standard pattern which seeks to resolve the
>
> current inconsistencies between some fdo database provider implementations.
>
>
> FDO should suggest a standard model, providers can still choose to
> implement them or not....
>
> In Orest's example with the oracle database, the database structure already
>
> exists, shouldn't we just try to represent that? the database supports the
> use
> of grants, synonyms, roles etc. there is an existing structure in place ..
>
> for example
>
> create user denver identified by tiger
> grant select on parcels.bolder
> create synonym parcel on parcels.bolder
>
> Isn't that a much better place to be managing this kind of thing? That way
> non FDO applications can also use the model.
>
>
> For example, removing the schema from SHP would result that you could have
>> 2 flavors of shp depending on the connection.  Connect to a single file and
>> you get no schema.  Connect to a directory and you get a schema name
>> "default".  SHP provider standardize to using "default" every time.
>>
>  Also applications relies on that standard: there will be a schema and it
>> will have a name.  This result in consistant representation of the schemas
>> and classes in a tree view for example. Changing this behavior has impacts
>> on applications relying on that standard.
>
>
> I agree the my suggestion of an empty schema would cause headaches, does
> FDO have the concept of
> a default schema? Ie GetDefaultSchema()?
>
> It's quite common to have qualified and unqualified naming for objects.
> Connect to oracle and I have access
> to both zac.region and region.
>
> So if FDO standardised along these lines, primarily for databases
> providers, updating an application to
> support this would mostly involve removing custom provider specific
> logic....
>
> A lot of applications wouldn't be affected at all, they just pull whatever
> structure the provider represents.
> Those which do, probably have a some custom case statements to handle each
> different provider's quirks.
>
> Updating such applications would basically involve stripping out such
> custom provider
> specific logic, which really doesn't sound to bad to me....
>
> Z
>
>>
>>
>> Robert
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org [mailto:
>> fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz Loskot
>> Sent: Friday, August 29, 2008 11:05 AM
>> To: FDO Internals Mail List
>> Subject: Re: [fdo-internals] Standardising FDO Schema's
>>
>> Orest Halustchak wrote:
>> > [...]
>> > The above is a logical schema. How could that be mapped to physical
>> > schema? The discussion started with Oracle. Let's say I have an
>> > Oracle instance called ORCL. The main physical grouping mechanism
>> > that Oracle has is an Oracle Owner. So, one mapping is that the FDO
>> > Data Store maps to Oracle Owner, then FDO Schema.Class maps to table.
>> > That keeps the integrated set of data within a single Oracle owner.
>> > Another mapping is to map FDO schema to Oracle Owner, i.e. define
>> > Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we
>> > separate CityOfDenver parcels from CityOfBoulder parcels? I could
>> > have DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping
>> > possible, and that's to use a separate Oracle instance for each data
>> > store, but users may not want to set up separate physical instances
>> > for this purpose, especially if they have a large number of data
>> > stores.
>>
>>
>> Orest,
>>
>> Thanks for the very in-depth explanation of schema naming issues.
>>
>> But we still need a consistent way to define and describe all
>> possibilities of mapping and naming paths in text.
>> As Zac proves, using only separators (like ::, ~, etc.) is insufficient.
>>
>> I think more self-describing approach is needed, perhaps we would use
>> XML or JSON for naming schemas?
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net
>> Charter Member of OSGeo, http://osgeo.org
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com (My Blog)
> +61 405 847 168
>



-- 
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080830/becfd462/attachment.html