I understand that without resources nothing of those would be done. I think it is great think that Autodesk would allocate resources to create new FDO provider for PostGIS and I think it is fine that you decide in which way to work..<div>
<br></div><div>My question was , is it necessary to replace old provider? Could old provider stay there at least for some time after release of new PostGIS provider ?</div><div><br></div><div>Haris<br><br><div class="gmail_quote">
On Mon, Nov 30, 2009 at 4:55 PM, Greg Boone <span dir="ltr"><<a href="mailto:greg.boone@autodesk.com">greg.boone@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"><span style="font-size:11.0pt;color:#1F497D">Hi Haris,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">One of the problems that the PostGIS provider user-community are
experiencing is a lack of development support from the community on some fairly
fundamental problems including connectivity, schema management, stability, and
unit testing. In all honestly, the current code base as it stands simply does
not meet the standards expected of a robust real-world deployment into a
customer site. In Orest’s email, he outlined a number of issues that have
been identified as road-blocks, and are not on anyone’s radar to address
in the 3.5 timeframe. While the GenericRDBMS code base is slightly more
complex, it has been proven to work, and work extremely well. Stability is not
an issue. Performance and schema management are sound. Memory management is
under control, etc. </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">If you strongly feel that the current code base is the better
option, how would address the fundamental problems seen in the current code
base, so that the provider could be successfully deployed to customer sites in
the 3.5 release timeframe?</span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Things that still need a fair bit of work include:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Creating new schema
and new data store</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Spatial filter
handling</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Huge memory leaks on
insert.</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Not all schema
commands are implemented.</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Enable and fix
transaction support.</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Constraint and
default values support.</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Lots of TODOs spread
all over the code</span></p>
<p><span style="font-family:Symbol;color:#1F497D"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:#1F497D">Virtually no unit
tests exist.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Greg</span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<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>] <b>On Behalf Of </b>Haris
Kurtagic<br>
<b>Sent:</b> Monday, November 30, 2009 10:26 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] FDO PostGIS provider developments</span></p>
</div>
<p class="MsoNormal"> </p>
</div><p class="MsoNormal">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.</p><div><div></div><div class="h5">
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Haris</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Mon, Nov 30, 2009 at 2:36 PM, Zac Spitzer <<a href="mailto:zac.spitzer@gmail.com" target="_blank">zac.spitzer@gmail.com</a>> wrote:</p>
<p class="MsoNormal">2009/12/1 Haris Kurtagic <<a href="mailto:haris@sl-king.com" target="_blank">haris@sl-king.com</a>>:</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> 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.</p>
</div>
<p class="MsoNormal">like?</p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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" target="_blank">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" 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>
><br>
><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>
><br>
<br>
<br>
</p>
</div>
</div>
<p class="MsoNormal"><span style="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</span></p>
<div>
<div>
<p class="MsoNormal">_______________________________________________<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></p>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div></div></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>