<div dir="ltr">Sticking with your oracle example, what can be achieved in terms with<br>custom mappings in terms of &quot;naming&quot; which can&#39;t <br>be achieved within the database, transparently to fdo? <br><br>the main one which comes to mind is for making the same data in which now <br>
resides in a postgis database appear to be the same data, but named, as it <br>used to be, when it was served thru the oracle provider?<br><br>z<br><br><div class="gmail_quote">On Sat, Aug 30, 2008 at 11:37 AM, Zac Spitzer <span dir="ltr">&lt;<a href="mailto:zac.spitzer@gmail.com">zac.spitzer@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="Ih2E3d">On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <span dir="ltr">&lt;<a href="mailto:robert.fortin@autodesk.com" target="_blank">robert.fortin@autodesk.com</a>&gt;</span> wrote:<br>
</div><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


As Orest said, FDO represents the data in different layer Datastore, Schema and Class. That&#39;s the rule. &nbsp;That&#39;s the standard.</blockquote></div><div><br>but currently there is no standard implementation pattern! that&#39;s the problem!<br>

&nbsp;</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The fact that some provider doesn&#39;t have/require schema doesn&#39;t mean we don&#39;t need a generic schema representation in FDO. &nbsp;It&#39;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&#39;t impose rules around the name of the schema. </blockquote>



</div><div><br>which means every implementation can be different! <br><br>just focussing on the DB side for a moment, should an app really care or need to know <br>about which fdo provider and which database i am using? Isn&#39;t FDO meant to flatten out all <br>

these differences?<br><br>I am just advocating adopting a standard pattern which seeks to resolve the <br>current inconsistencies between some fdo database provider implementations. <br><br>FDO should suggest a standard model, providers can still choose to implement them or not....<br>


<br>In Orest&#39;s example with the oracle database, the database structure already <br>exists, shouldn&#39;t we just try to represent that? the database supports the use <br>of grants, synonyms, roles etc. there is an existing structure in place ..<br>

<br>for example <br><br>create user denver identified by tiger<br>grant select on parcels.bolder<br>create synonym parcel on parcels.bolder<br><br>Isn&#39;t that a much better place to be managing this kind of thing? That way <br>

non FDO applications can also use the model.<br><br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For example, removing the schema from SHP would result that you could have 2 flavors of shp depending on the connection. &nbsp;Connect to a single file and you get no schema. &nbsp;Connect to a directory and you get a schema name &quot;default&quot;. &nbsp;SHP provider standardize to using &quot;default&quot; every time.<br>


</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also applications relies on that standard: there will be a schema and it will have a name. &nbsp;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.</blockquote>


</div><div><br>I agree the my suggestion of an empty schema would cause headaches, does FDO have the concept of <br>a default schema? Ie GetDefaultSchema()?<br><br>It&#39;s quite common to have qualified and unqualified naming for objects. Connect to oracle and I have access<br>

to both zac.region and region.<br></div>
<div><br>So if FDO standardised along these lines, primarily for databases providers, updating an application to <br>support this would mostly involve removing custom provider specific logic....<br><br>A lot of applications wouldn&#39;t be affected at all, they just pull whatever structure the provider represents. <br>


Those which do, probably have a some custom case statements to handle each different provider&#39;s quirks.<br><br>Updating such applications would basically involve stripping out such custom provider <br>specific logic, which really doesn&#39;t sound to bad to me.... <br>
<font color="#888888">
<br> Z</font></div><div><div></div><div class="Wj3C7c">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
Robert<br>
</font><div><div></div><div><br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>] On Behalf Of Mateusz Loskot<br>




Sent: Friday, August 29, 2008 11:05 AM<br>
To: FDO Internals Mail List<br>
Subject: Re: [fdo-internals] Standardising FDO Schema&#39;s<br>
<br>
Orest Halustchak wrote:<br>
&gt; [...]<br>
&gt; The above is a logical schema. How could that be mapped to physical<br>
&gt; schema? The discussion started with Oracle. Let&#39;s say I have an<br>
&gt; Oracle instance called ORCL. The main physical grouping mechanism<br>
&gt; that Oracle has is an Oracle Owner. So, one mapping is that the FDO<br>
&gt; Data Store maps to Oracle Owner, then FDO Schema.Class maps to table.<br>
&gt; That keeps the integrated set of data within a single Oracle owner.<br>
&gt; Another mapping is to map FDO schema to Oracle Owner, i.e. define<br>
&gt; Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we<br>
&gt; separate CityOfDenver parcels from CityOfBoulder parcels? I could<br>
&gt; have DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping<br>
&gt; possible, and that&#39;s to use a separate Oracle instance for each data<br>
&gt; store, but users may not want to set up separate physical instances<br>
&gt; for this purpose, especially if they have a large number of data<br>
&gt; stores.<br>
<br>
<br>
Orest,<br>
<br>
Thanks for the very in-depth explanation of schema naming issues.<br>
<br>
But we still need a consistent way to define and describe all<br>
possibilities of mapping and naming paths in text.<br>
As Zac proves, using only separators (like ::, ~, etc.) is insufficient.<br>
<br>
I think more self-describing approach is needed, perhaps we would use<br>
XML or JSON for naming schemas?<br>
<br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" target="_blank">http://mateusz.loskot.net</a><br>
Charter Member of OSGeo, <a href="http://osgeo.org" target="_blank">http://osgeo.org</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
</div></div><br>_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
<br></blockquote></div></div></div><br><br clear="all"><div class="Ih2E3d"><br>-- <br>Zac Spitzer -<br><a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a> (My Blog)<br>+61 405 847 168<br>

</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Zac Spitzer -<br><a href="http://zacster.blogspot.com">http://zacster.blogspot.com</a> (My Blog)<br>+61 405 847 168<br>
</div>