I wouldn't like to go to much into discussion about generic rdbms stuff. I think that priority should be having good PostGIS provider which we can get with current resources.<div><br></div><div>Just in short, when I started looking how to make provider for Oracle, Generic RDBMS was first place to start looking. For me Generic RDBMS was to complex , hard to work with and extend . Performance was also bad.</div>
<div>That was few years ago, I would assume that it has improved since but still I am afraid that Autodesk would be only maintaner of that code. That would be main reason why I would like to have current PostGIS available, which has not only Autodesk developers which could work on it.</div>
<div><br></div><div>Haris</div><div><div><br></div><div><br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 2:36 PM, Zac Spitzer <span dir="ltr"><<a href="mailto:zac.spitzer@gmail.com">zac.spitzer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2009/12/1 Haris Kurtagic <<a href="mailto:haris@sl-king.com">haris@sl-king.com</a>>:<br>
<div class="im">> Is it necessary to replace current version, can't that be another version of<br>
> provider ?<br>
> I was never able to get comfortable with generic rdbms stuff. In my opinion<br>
> there are minuses too.<br>
<br>
</div>like?<br>
<div><div></div><div class="h5"><br>
> I would like to have option of current code base to be continued if there<br>
> would be option at least for some time.<br>
> Haris<br>
><br>
> On Mon, Nov 30, 2009 at 2:14 AM, Orest Halustchak<br>
> <<a href="mailto:orest.halustchak@autodesk.com">orest.halustchak@autodesk.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> Autodesk has had interest from Map3D customers who want to use the FDO<br>
>> PostGIS provider to access and edit data using Map3D and other products.<br>
>><br>
>><br>
>><br>
>> These customers have not been able to use this provider reliably with<br>
>> Map3D. We had a close look at the provider code to determine what work would<br>
>> be needed to complete the implementation of schema and edit support and fix<br>
>> other issues. Unfortunately, we found that the provider as it stands today<br>
>> requires a lot of work to complete the implementation of required FDO<br>
>> interfaces and to add good unit test coverage. Things that still need a fair<br>
>> bit of work include:<br>
>><br>
>> · Creating new schema and new datastore<br>
>><br>
>> · Spatial filter handling<br>
>><br>
>> · Huge memory leaks on insert.<br>
>><br>
>> · Not all schema commands are implemented.<br>
>><br>
>> · Enable and fix transaction support.<br>
>><br>
>> · Constraint and default values support.<br>
>><br>
>> · Lots of TODOs spread all over the code<br>
>><br>
>> · Virtually no unit tests exist.<br>
>><br>
>><br>
>><br>
>> We looked at the level of effort needed to complete that work. It was<br>
>> quite high. So, we looked at an alternative. There exists an earlier open<br>
>> source community code base for a PostGIS provider that was started a couple<br>
>> of years ago but not finished. That code base used the generic rdbms<br>
>> framework that is shared with the SQL Server Spatial, MySQL, and ODBC<br>
>> providers. Most of the schema processing is handled with that shared code.<br>
>> We spent some time working with the current provider and the other code base<br>
>> to determine the most efficient way to get to a completed provider that<br>
>> would be robust, perform well, and be maintainable.<br>
>><br>
>><br>
>><br>
>> In the end, we determined that taking the earlier code base, adding<br>
>> support for the recent fdo interface changes, and completing other parts<br>
>> that weren’t finished would take much less time. Also, based on performance<br>
>> comparisons, we would get something that was much faster on inserts and<br>
>> selects, e.g. the select performance is about six times faster and schema<br>
>> describe is about three times faster. We couldn’t compare insert times very<br>
>> well because the current provider kept crashing after a certain point and we<br>
>> couldn’t insert a large number of features.<br>
>><br>
>><br>
>><br>
>> So, what we would like to do is complete our work to get a working PostGIS<br>
>> provider and then replace the current open source code with our new copy.<br>
>> Note that we plan to use native PostGIS schema without adding additional<br>
>> metadata tables just as the current provider does. It will be able to read<br>
>> any schemas created by the current version of the provider and itself will<br>
>> generate generic PostGIS schemas.<br>
>><br>
>><br>
>><br>
>> We’ll need to submit an RFC for this, but we wanted to get this<br>
>> information out to you ahead of time.<br>
>><br>
>><br>
>><br>
>> At the same time, we are planning to change the connection parameters to<br>
>> separate out the database name from the service name. This will make it<br>
>> easier for users. They can identify the service (e.g. localhost:5432), and<br>
>> then see the available datastores from which they can choose in a UI. Then,<br>
>> PostGIS schema simply will map to FDO schema. The main drawback to this is<br>
>> that any users with existing MapGuide feature sources and layer definitions<br>
>> will have to update them.<br>
>><br>
>><br>
>><br>
>> In the end, we will end up with a good functioning provider that performs<br>
>> well.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> Orest.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> fdo-internals mailing list<br>
>> <a href="mailto:fdo-internals@lists.osgeo.org">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>
><br>
><br>
> _______________________________________________<br>
> fdo-internals mailing list<br>
> <a href="mailto:fdo-internals@lists.osgeo.org">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>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Zac Spitzer<br>
Solution Architect / Director<br>
Ennoble Consultancy Australia<br>
<a href="http://www.ennoble.com.au" target="_blank">http://www.ennoble.com.au</a><br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a><br>
+61 405 847 168<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">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></blockquote></div><br></div></div>