Opened 14 years ago

Last modified 14 years ago

#3550 new defect

Why do we have different MS_SINGLE/MULTIPLE and MS_QUERY_SINGLE/MULTIPLE constants

Reported by: dmorissette Owned by: sdlime
Priority: normal Milestone: 6.0 release
Component: MapServer C Library Version: unspecified
Severity: normal Keywords:
Cc: sdlime

Description

While looking at the WMS GetFeatureInfo code, I noticed that in some places for query mode we use MS_SINGLE/MS_MULTIPLE, and in the query functions we use MS_QUERY_SINGLE and MS_QUERY_MULTIPLE.

#define MS_SINGLE 0 /* modes for searching (spatial/database) */
#define MS_MULTIPLE 1

enum MS_QUERY_MODE {MS_QUERY_SINGLE, MS_QUERY_MULTIPLE};

By chance they have the same values so things work fine this way, but why do we have two sets of constants for the same thing?

Any objections to getting rid of MS_SINGLE and MS_MULTIPLE?

Change History (2)

comment:1 by dmorissette, 14 years ago

Owner: changed from dmorissette to sdlime

I have fixed mapwms.c and maprasterquery.c in SVN trunk r10518 to use MS_QUERY_SINGLE/MS_QUERY_MULTIPLE instead of MS_SINGLE/MS_MULTIPLE.

That leaves only one place still using MS_MULTIPLE in mapfile.c's loadJoin():

if((join->type == MS_MULTIPLE) && ((join->template == NULL) || (join->name == NULL))) {
  msSetError(MS_EOFERR, "One-to-many joins must define template and name properties.", "loadJoin()");
  return(-1);
}      

Presumably we should be using MS_ONE_TO_MANY here instead of MS_MULTIPLE and once again we've been lucky that both constants have the same value.

I will reassign to you Steve to confirm and deal with this...

Well, I also see SINGLE and MULTIPLE keywords defined in maplexer.l ... are they legacy from the past? Are they still in use today?

comment:2 by sdlime, 14 years ago

My bad on the changes you had to make. With the query overhaul in 5.6 I wanted to be explicit with the constants associated with queries rather than sharing. The values were chosen to be the same as the old constants just in case.

The MULTIPLE keyword is still in use with joins and will remain, although the constant should change as suggested.

Will clean it up...

Steve

Note: See TracTickets for help on using tickets.