Open restjohn opened 9 years ago
tkunicki
commented
9 years ago Arrays were ignored due to issues with GeoServer supporting literal feature attributes w/ cardinalities > 1. What's the strategy for handling arrays with more than one element?
restjohn
commented
9 years ago The strategy in the referencing pull request #84 is to continue ignoring them, but in a way that does not throw uncaught exceptions when creating a MongoDB Store pointing to data that contains arrays.
jodygarnett
commented
7 years ago This project has been donated to geotools community:
It will be marked supported when it meets documentation and quality assurance requirements.
Using GeoServer 2.7.1 Stable Using gt-mongodb extension, 2.7-SNAPSHOT built from master (e173782a0e1d64e3681e55eaed1f9a233d829383)
The mongodb extension fails when a collection has either an index that references the property of an object in a nested array, or when accessing documents with a key path pointing to values of objects in an array nested in the documents.
For example, an index on the key path
attachments.lastModified, whereattachmentsis a document key that references an array of objects, which in turn have a keylastModifiedthat references a scalar value, will cause the errors in steps 6 and 8 below. Additionally, in the absence of such an index, simply a document with that same structure will cause the error in step 11. Here is a concrete example of the symptomatic document structure:Reproducing the errors
In the Bounding Boxes section, click either of compute from data/compute from native bounds. The app shows the following error on a web page and in the server log.
Save the layer. The app shows the following error on a web page and in the server log. The app should still save the layer, however.
Click on a feature on the map. The browser should download a file called
wms, and the following error appears in the log. Thewmsfile should also contain the message text of the exception.