My second question of the day regarding REST JSON... sorry
I am experiencing issues deserializing some REST JSON responses where the
response schema changes depending on the output. I know that JSON doesn't
support schemas in the .xsd sense, but I at least expect the response
structure to be the same across different kinds of responses.
For example
If I query the data stores within a workspace that does contain data stores
the response looks like this:
{"dataStores":{"dataStore":[{"name":"...","href":"..."},{"name":"...","href":"..."}]}}
However if the workspace contains no data stores the response looks like
this:
{"dataStores":""}
when I would expect it to look like this:
{"dataStores":{"dataStore":}}
This makes it impossible for me to deserialize the response into a single
type (in Java). I can overload my class's dataStores setter (setDataStores)
to accept both a String and a dataStore collection, but my class can only
have one property called dataStores and this must be either a String or a
collection.
This means that I have to inspect the text of the JSON response before I
attempt deserialization, which feels like a bad workaround.
Is this by design? Should I submit a feature request? And can anyone
convince me that this is a good idea?
Thanks
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Inconsistency-in-REST-JSON-responses-tp4982837.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Very basic question here, but I can't seem to find any documentation on it:
When creating a store using Oracle JNDI, I have the option for "Estimated Extends". I can't seem to find any documentation on this option. Could someone explain what exactly this does and when I would want to have this on or off?
_____________________________________________
Ivan Suftin - Applications Developer - isuftin@anonymised.com
Office: (608) 821-3825 - Cell : (608) 345-8963
Center for Integrated Data Analytics - http://cida.usgs.gov/
United States Geological Survey
8505 Research Way, Middleton, WI 53562
Where a calculator like the ENIAC today is equipped with
18,000 vacuum tubes and weighs 30 tons, computers in
the future may have only 1,000 vacuum tubes and perhaps
weigh only 1½ tons.
- Andrew Hamilton, Popular Mechanics, 1949
Looks like a bug to me. I am curious to know if the same thing happens with xml.
Anyways, can you create an issue in JIRA for this. Thanks.
-Justin
On Wed, Jun 20, 2012 at 6:02 PM, cheesybiscuits <thomaschristian@anonymised.com.84…> wrote:
My second question of the day regarding REST JSON… sorry
I am experiencing issues deserializing some REST JSON responses where the
response schema changes depending on the output. I know that JSON doesn’t
support schemas in the .xsd sense, but I at least expect the response
structure to be the same across different kinds of responses.
For example
If I query the data stores within a workspace that does contain data stores
the response looks like this:
{“dataStores”:{“dataStore”:[{“name”:“…”,“href”:“…”},{“name”:“…”,“href”:“…”}]}}
However if the workspace contains no data stores the response looks like
this:
{“dataStores”:“”}
when I would expect it to look like this:
{“dataStores”:{“dataStore”:}}
This makes it impossible for me to deserialize the response into a single
type (in Java). I can overload my class’s dataStores setter (setDataStores)
to accept both a String and a dataStore collection, but my class can only
have one property called dataStores and this must be either a String or a
collection.
This means that I have to inspect the text of the JSON response before I
attempt deserialization, which feels like a bad workaround.
Is this by design? Should I submit a feature request? And can anyone
convince me that this is a good idea?
Thanks
–
View this message in context: http://osgeo-org.1560.n6.nabble.com/Inconsistency-in-REST-JSON-responses-tp4982837.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Thu, Jun 21, 2012 at 9:31 PM, Ivan Suftin <isuftin@anonymised.com> wrote:
Very basic question here, but I can’t seem to find any documentation on it:
When creating a store using Oracle JNDI, I have the option for “Estimated Extends”. I can’t seem to find any documentation on this option. Could someone explain what exactly this does and when I would want to have this on or off?
When the option is on the code will try to compute the extent using select SDO_TUNE.EXTENT_OF(‘TABLE’, 'GEOM) FROM DUAL,
which peeks the top of the spatial index instad of computing the actual bounds.
When not enabled SDO_AGGR_MBR will be used instead, which results in a full table scan instead (and provides an accurate result).
Extent computation is mostly used when configuring the layers (compute native bbox link), but also by WPS processes like gs:Bounds
and by WFS when the “feature bouding” option is enabled.
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf