[mapguide-trac] #708: Exceptions thrown on SELECTFEATURES instead of being handled gracefully.

MapGuide Open Source trac_mapguide at osgeo.org
Wed Apr 14 09:07:50 EDT 2010


#708: Exceptions thrown on SELECTFEATURES instead of being handled gracefully.
-----------------------+----------------------------------------------------
 Reporter:  jng        |         Owner:       
     Type:  defect     |        Status:  new  
 Priority:  high       |     Milestone:       
Component:  Map Agent  |       Version:  2.1.0
 Severity:  critical   |    Resolution:       
 Keywords:             |   External_id:       
-----------------------+----------------------------------------------------
Comment (by tomfukushima):

 (Adding the comments that I sent to mapguide-internals to this ticket...)

 I'm looking at the !MgProperty_XmlSerialization_NullValues.patch and it's
 close, but I think our schema is wrong.  I believe these changes are for
 the schema defined by !BatchPropertyCollection-1.0.0.xsd.

 To be able to define null values, we only need to not specify the <Value>
 element.  For example, to specify Owner=null we would write
 <Name>Owner</Name><Type>string</Type>.  Compare with Owner="Tom" which is
 specified as <Name>Owner</Name><Type>string</Type><Value>Tom</Value>.
 Unfortunately our schema doesn't allow this because the Value element has
 the (default) constraints of minoccurs=1 and maxoccurs=1.  I think that we
 should change the schema so that the value element is defined as:
   <xs:element name="Value" type="xs:string" minOccurs="0"/>
 Once we do this, then we can specify null values as above.

 Strictly speaking, we would need to rev the schema, but I wonder if we
 would be able to get away with making the change in place this time (i.e.,
 just updating the 1.0.0 schema).  I guess, the problem would be if there
 are any clients that consume this format; they will need to be able to
 handle the case where the value elements are missing---however, given that
 no one has probably been able to use this because null values have caused
 crashes, I think no one would be affected.  Not sure though, anyone see
 any problems with treating this as a bug in the schema and just fixing it?

 Jackie's reply:
 If SELECTFEATURES is the only means through which this format can be
 consumed, then I think an in-place update is fine, seeing (as you already
 know) the operation hasn't worked properly in over 1.5 years.

 Jason's reply: Is there JSON output for this? If so, how do you handle
 nulls for JSON output?  I think there may be a native NULL type?

 Jackie's reply: If there is, it isn't working:

 http://trac.osgeo.org/mapguide/ticket/1104

 But handling nulls would probably be the same, javascript can easily test
 for existence of object properties. So no "value" property -> null value.

-- 
Ticket URL: <http://trac.osgeo.org/mapguide/ticket/708#comment:3>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals


More information about the mapguide-trac mailing list