Is it necessary to replace current version, can't that be another version of provider ?<div><br></div><div>I was never able to get comfortable with generic rdbms stuff. In my opinion there are minuses too.</div><div>I would like to have option of current code base to be continued if there would be option at least for some time.</div>
<div><br></div><div>Haris<br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 2:14 AM, Orest Halustchak <span dir="ltr"><<a href="mailto:orest.halustchak@autodesk.com">orest.halustchak@autodesk.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Autodesk has had interest from Map3D customers who want to
use the FDO PostGIS provider to access and edit data using Map3D and other
products.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">These customers have not been able to use this provider
reliably with Map3D. We had a close look at the provider code to determine what
work would be needed to complete the implementation of schema and edit support
and fix other issues. Unfortunately, we found that the provider as it stands
today requires a lot of work to complete the implementation of required FDO
interfaces and to add good unit test coverage. Things that still need a fair
bit of work include:</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Creating new schema and new datastore</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Spatial filter handling</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Huge memory leaks on insert.</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Not all schema commands are implemented.</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Enable and fix transaction support.</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Constraint and default values support.</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Lots of TODOs spread all over the code</p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span>Virtually no unit tests exist.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We looked at the level of effort needed to complete that
work. It was quite high. So, we looked at an alternative. There exists an
earlier open source community code base for a PostGIS provider that was started
a couple of years ago but not finished. That code base used the generic rdbms
framework that is shared with the SQL Server Spatial, MySQL, and ODBC
providers. Most of the schema processing is handled with that shared code. We
spent some time working with the current provider and the other code base to
determine the most efficient way to get to a completed provider that would be
robust, perform well, and be maintainable.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In the end, we determined that taking the earlier code base,
adding support for the recent fdo interface changes, and completing other parts
that weren’t finished would take much less time. Also, based on
performance comparisons, we would get something that was much faster on inserts
and selects, e.g. the select performance is about six times faster and schema
describe is about three times faster. We couldn’t compare insert times
very well because the current provider kept crashing after a certain point and
we couldn’t insert a large number of features.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">So, what we would like to do is complete our work to get a
working PostGIS provider and then replace the current open source code with our
new copy. Note that we plan to use native PostGIS schema without adding
additional metadata tables just as the current provider does. It will be able
to read any schemas created by the current version of the provider and itself
will generate generic PostGIS schemas.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We’ll need to submit an RFC for this, but we wanted to
get this information out to you ahead of time.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">At the same time, we are planning to change the connection
parameters to separate out the database name from the service name. This will
make it easier for users. They can identify the service (e.g. localhost:5432),
and then see the available datastores from which they can choose in a UI. Then,
PostGIS schema simply will map to FDO schema. The main drawback to this is that
any users with existing MapGuide feature sources and layer definitions will
have to update them.<span style="color:#1F497D"></span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In the end, we will end up with a good functioning provider
that performs well.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Regards,</p>
<p class="MsoNormal">Orest.</p>
<p class="MsoNormal"> </p>
</div>
</div>
<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></blockquote></div><br></div>