Fix for bug #1629

[Umberto Nicoletti]

On 2/1/06, Daniel Morissette <dmorissette at dmsolutions.ca> wrote:
> Umberto Nicoletti wrote:
> > I have checked out HEAD and verified on a map of my own the the bug
> > exists by defining both FILTER and FILTERITEM on a layer. If I removed
> > the FILTERITEM then the map worked again as expected.
> >
> > Then I have applied my patch and verified that the map worked again with:
> > -both FILTER and FILTERITEM
> > -only with FILTER
> > -only with FILTERITEM
> >
> > I used the following values in the test:
> >
> > FILTER = ' myattribute=A OR myattribute=B '
> > FILTERITEM='myattribute'
> >
> > Last but not least I checked the Oracle spatial code and can confirm
> > (If I understood correctly) that the behaviour of postgis with my
> > patch matches that of Oracle Spatial, that is the FILTERITEM is
> > ignored (as the docs say).
> >
> > To be frank I have not tested using msSearchByAttribute because that
> > would have required some more time (which I really do not have) but
> > for what I know they should end up calling the same functions, so the
> > tests are to be considered valid.
> >
> > I hope this answers your question.
> >
>
> Um... I was more hoping for a "yes it's safe and if I'm wrong then I owe
> each of you a beer for having delayed the release" type of answer. ;)
>

In fact I was goind to answer like that, but I'm the new guy here, so
I though it'd been polite to be verbose :-)

> I am not familiar enough with the mappostgis.c implementation to tell
> whether there is potential for side-effects so I have to conclude that
> it's not safe to backport this a few days before the release.
>

Agree, if someone makes a win32 release for the person who reported
the bug then he could confirm whether the issue is solved or not.

> > Note 1: we should really set up some automated tests for stuff like
> > this and in particular for regression testing and integrate them in
> > the build process.
> >
>
> Agreed. Does this mean you're offering to contribute some tests for Sean
> or Frank's test suites? ;)

I was thinking about something like that. Stay tuned.

>
> > Note 2: I think that we should delay 4.8: better late but working than
> > in time but with errors.
> >
>
> I really think it's been delayed enough, we're already 6 weeks passed
> the original date and it's not like this bug affects a large number of
> users anyway, right? How about we document the issue for 4.8.0 and
> backport the fix to 4.8.1?

I suppose everybody else agrees with you so it's okay with me too.

Umberto

>
> Sorry to be a pain, it's not your fault specifically, but I've been
> reminded a few days ago that I have been too easy as release manager
> this time in letting last minute stuff sneak in and betas end up late,
> which caused this 6 weeks release delay... and I think the comment was
> legitimate, so we're getting back on track with the 4.8.0 release
> tomorrow unless I hear strong objections.
>
> Daniel
> --
> ------------------------------------------------------------
>   Daniel Morissette               dmorissette at dmsolutions.ca
>   DM Solutions Group              http://www.dmsolutions.ca/
> ------------------------------------------------------------
>