[prev in list] [next in list] [prev in thread] [next in thread]
List: fdo-internals
Subject: [fdo-internals] PATCH : PostGIS provider patch 3.4
From: chuckwilbur () spatialnet ! net (Chuck Wilbur)
Date: 2008-04-22 12:17:30
Message-ID: EFEMKLOIGHBKFJMLFGLNGELACNAA.chuckwilbur () spatialnet ! net
[Download RAW message or body]
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@geomapgis.com]
> Sent: Tuesday, April 22, 2008 7:59 AM
> To: fdo-internals@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@geomapgis.com]
> > > Sent: Thursday, April 17, 2008 8:50 AM
> > > To: fdo-internals@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@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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic