[fdo-internals] PATCH : PostGIS provider patch 3.4
Chuck Wilbur
chuckwilbur at spatialnet.net
Tue Apr 22 12:17:28 EDT 2008
Bruno,
Thanks for the quick response.
I'm glad the first problem makes sense to you. Your explanation makes sense to me, but looking at it yesterday I was completely puzzled. I can certainly work around the problem by dropping the test schema manually before running my unit tests.
I've been trying to remember for sure whether parameterized queries worked with the previous version of the provider. Ah, I'm sure now they did because I found my email to Mateusz last year on the topic:
> > Your binaries are impressively complete. Aside from tweaking the
> > schema name and some other changes having to do with passing simple
> > table queries to postgresql, most of my test harness works with your
> > binaries. Yours is also the first provider I've used that actually
> > has parameterized queries (FdoParameterValueCollection) implemented.
It's possible postgres has moved on without me and broken this - I haven't updated in a while. What version are you building/testing against?
> -----Original Message-----
> From: Bruno Scott [mailto:bscott at geomapgis.com]
> Sent: Tuesday, April 22, 2008 7:59 AM
> To: fdo-internals at lists.osgeo.org
> Subject: RE: [fdo-internals] PATCH : PostGIS provider patch 3.4
>
>
>
> Hi Chuck,
>
> For your first point, i think i have an idea of what's going on.
> Actually the provider does a describschema at first connection and caches
> all the table descriptions.
> It does that for speed.
> I think the problem would be that the internal cache is not well updated
> when you delete and recreate a table. I'm not at my office for the moment
> but i will take a look at this when i will be back.
> We have our own unit testing engine, but the difference with yours is we
> create and populate all the tables in a pre process batch job. We
> lauch our
> test after, so the cache is always ok in our situation.
>
> For you second point, i haven't do any testing on parameterized query at
> all. They maybe not implemented yet. I will take a look at this also.
>
> Bruno
>
>
> Chuck Wilbur wrote:
> >
> > Hi Bruno,
> >
> > I've grabbed your binaries and plugged them into my test application (a
> > small C++ app that simply uses direct calls into FDO to
> manipulate a data
> > store). I've run into two problems so far:
> >
> > 1)
> > I have some initial cleanup code that makes sure the test tables/classes
> > have been cleared and deleted (I can report that defect 106
> appears to be
> > fixed because this works now). If the test class is not present when I
> > start the testing, it gets created and I can successfully
> insert features.
> > However, if the test class is present and has to be cleared,
> deleted, and
> > then recreated (I stepped through the code and checked the database and
> > confirmed that all these steps are happening), the subsequent insertions
> > fail with an exception at FdoIInsert::Execute. Perhaps this is
> related to
> > the insert failure in a table with an srid that I just read about.
> > Unhandled exception at 0x0845fcc0 in TestSuite.exe: 0xC0000005: Access
> > violation reading location 0x00000000.
> >
> > 2)
> > I'm creating a class named testclassdata with a field named
> intfield with
> > integer data (and other fields, including feature id and
> geometry). When I
> > attempt to build a parameterized query against intfield (WHERE
> intField >
> > $1) FDO throws an exception with the messages:
> > String does not represent a valid filter.
> > String incorrectly formatted.
> > I tracked these messages to FdoParse::ParseFilter in Parse.cpp, and they
> > seem to indicate that fdo_filter_yyparse is failing, but since
> I'm working
> > off compiled binaries I can't get much farther than that. It's not even
> > clear to me from reviewing the code where fdo_filter_yyparse calls into
> > the PostGIS provider (nearly identical testing code with "?" instead of
> > "$1" works with Autodesk's Oracle provider, so I assume the PostGIS
> > provider is at fault).
> >
> > Testing code (paraphrased):
> > FdoIConnection* m_connection; // code to set up and connect omitted
> > FdoISelect* m_pSelectCmd;
> > try
> > {
> > m_pSelectCmd = dynamic_cast<FdoISelect*>(
> >
> m_connection->CreateCommand(FdoCommandType_Select) );
> > m_pSelectCmd->SetFeatureClassName( L"testclassdata" );
> >
> > FdoPtr<FdoParameterValueCollection> params =
> > m_pSelectCmd->GetParameterValues();
> > FdoLiteralValue *value = FdoInt32Value::Create(10000);
> > if ( params )
> > {
> > FdoStringP paramName;
> > paramName = FdoStringP::Format(L"$1");
> > FdoPtr<FdoParameterValue> param =
> params->FindItem(paramName);
> > if ( !param )
> > {
> > param =
> FdoParameterValue::Create(paramName);
> > params->Add(param);
> > }
> > param->SetValue(value);
> > m_pSelectCmd->SetFilter( L"intfield > $1"
> ); // Exception occurs here
> > }
> > }
> >
> >
> >> -----Original Message-----
> >> From: Bruno Scott [mailto:bscott at geomapgis.com]
> >> Sent: Thursday, April 17, 2008 8:50 AM
> >> To: fdo-internals at lists.osgeo.org
> >> Subject: [fdo-internals] PATCH : PostGIS provider patch 3.4
> >>
> >>
> >>
> >> This is a pretty big Patch I know.
> >> Many of the tickets were related in a way or another.
> >> It has became very hard to have lots a small patches
> >> The next patch will be : one ticket for one patch J
> >>
> >>
> >> Ticket fixed by this patch
> >>
> >> #94 Generate extent for features assigned to default spatial context
> >> #106 PostGIS provider cannot delete a feature class
> >> #171 Fdo Postgis Autogenated identity property is mandatory
> >> #178 PostGIS : Can't insert in a non-feature class
> >> #232 Fdo Postgis null and not null filter does not work
> >> #233 Fdo Postgis in and not in filter does not work
> >> #234 Fdo Postgis currently does not support anything but lowercase
> >> identifiers
> >> #235 Fdo Postgis Exception with insert
> >> #236 Fdo Postgis does not support non spatial classes
> >> #241 Implement Support for SelectAggregates, SpatialExtents and Count
> >> #310 PostGIS provider : change class naming convention without ~
> >> #311 PostGIS provider : mismatch between FdoGeometricTypes and
> >> FdoGeometryType
> >> #312 PostGIS provider : remove boost_date_time dll dependency
> >> #313 PostGIS provider : can't filter,insert or update date/datetime
> >> #314 PostGIS provider : check-out/check-in crashes Autodesk Map
> >>
> >>
> >> I have included binaries, it’s easier to test than recompiling
> >> everythingJ
> >> These binaries have been tested on Map 2009
> >>
> >> Patches and binaries for Branch\3.3 and for 3.2.3 will follow
> >>
> >> Bruno
> >> http://www.nabble.com/file/p16744011/PostGIS_trunk_patch.zip
> >> PostGIS_trunk_patch.zip
> >> http://www.nabble.com/file/p16744011/PostGIS_trunk_binaries.zip
> >> PostGIS_trunk_binaries.zip
> >> --
> >> View this message in context:
> >> http://www.nabble.com/PATCH-%3A-PostGIS-provider-patch-3.4-tp16744
> > 011s18162p16744011.html
> > Sent from the fdo-internals mailing list archive at Nabble.com.
> >
> >
> >
> > _______________________________________________
> > fdo-internals mailing list
> > fdo-internals at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/fdo-internals
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/PATCH-%3A-PostGIS-provider-patch-3.4-tp16744
011s18162p16824010.html
Sent from the fdo-internals mailing list archive at Nabble.com.
More information about the fdo-internals
mailing list