Bug with FID special field handling.

[warmerdam]

Never mind this, I think I found the problem. There was a missing break
statement in the following code:

        if ( iSpecialField < SPECIAL_FIELD_COUNT )
        {
            switch ( SpecialFieldTypes[iSpecialField] )
            {
            case SWQ_INTEGER:
                sField.Integer = poFeature->GetFieldAsInteger(
op->field_index );
/***/              break;
            case SWQ_STRING:
                sField.String = (char*) poFeature->GetFieldAsString(
op->field_index );
            }      
        }


In the function OGRFeatureQueryEvaluator(). Adding the break after the
SWQ_INTEGER case fixed query on FIDs.


Traian
 

-----Original Message-----
From: Traian Stanev 
Sent: Wednesday, January 31, 2007 4:14 PM
To: Frank Warmerdam (External)
Subject: RE: [mapguide-internals] ogr postgis layer problems


Hi Frank,

I'm debugging the problem Paul is having. I think I found a problem in
OGR when a filter of the form "FID = 365" is used.
Around line 431 of OgrFeatureQuery.cpp, there is the following line:

poIndex = poLayer->GetIndex()->GetFieldIndex( psExpr->field_index );

When the query is on FID, this returns NULL, resulting in the query
returning no features. The field index used for FID seems to be a
special index that's one bigger than the highes attribute field index of
the layer. Any ideas about what I could do (in terms of calls to OGR) to
avoid having to add special filter handling on the side of the FDO
provider?


I'm using GDAL 1.4.0.



Traian

[warmerdam]

Fixed bug in trunk and added test in autotest/ogr/ogr_basic_test.py for
fid (special field) queries - ogr_basic_5. 

Migrated fix and test into 1.4 branch as well.