1

Here is my schema (simple schema):

officelocation: {
type: String,
label: 'Location of Office',
autoform: {
  type: 'map',
  afFieldInput: {
    type: 'map',
    geolocation: true,
    searchBox: true,
    autolocate: true
  }
}
},
location: {
  optional: true,
  type: 'Point'
}

My server side js code is below (note this is in a collection.after hook) so I want to update it based on the address that user has entered, which I have resolved into lat long:

Providers.update({_id: doc._id}, {$set: {location: {type:"Point", coordinates:[lng,lat]} } });

When I see the file in the collection (db.providers.find();), I see the below.. Note that the location embedded object is empty:

{ "_id" : "X8ZfKYJAP9cduwvmd",  "phone" : 999999999, "officelocation" : "40.7192714,14.872363899999982", "createdAt" : ISODate("2015-04-24T02:00:40.447Z"), "updatedAt" : ISODate("2015-04-24T02:00:40.799Z"), "owner" : "GB4TxTHodkykeeXp6", "officeaddress" : "Via Califri, 5, 84099 San Cipriano Picentino SA, Italy", "location" : {  } }

I am basically trying to make sure by collections are stored in a geo-spatial-searchable way, but this approach does not seem to work. Any help?

Abhishek Sunku
  • 41
  • 2
  • 8

1 Answers1

0

There could be a number of things causing your update to fail, from allow-deny rules to Simple Schema cleaning out your data.

I see that you are using a custom type to store your location. Make sure you have used a Transform to ensure the type isn't lost on the way to the server. From the Simple Schema readme:

Custom object types are treated as blackbox objects by default. However, when using collection2, you must ensure that the custom type is not lost between client and server. This can be done with a transform function that converts the generic Object to the custom object. Without this transformation, client-side inserts and updates might succeed on the client but then fail on the server. Alternatively, if you don't care about losing the custom type, you can explicitly set blackbox: true for a custom object type instead of using a transformation.

Alternatively you could use a sub-schema to define what a location is allowed to look like, instead of using a custom type, but it won't keep the methods of the Point type.

Thaum Rystra
  • 740
  • 7
  • 14
  • I do not fully understand. 1) This should take care of allowing inserts: `Providers.allow({ insert: function(userId, doc) { return true;}});`. 2) I found this question [link](http://stackoverflow.com/questions/24492333/meteor-simple-schema-for-mongo-geo-location-data) which I believe is what you are suggesting with sub-schema. But I am struggling to figure out how to update this object now? In @chaosbohne's example, would something like `Providers.update({_id: doc._id}, {$set: {loc: {type:"Point", coordinate:{lng:22.122,lat:-122.212} } } });` work? – Abhishek Sunku Apr 24 '15 at 06:04
  • 1) Yes, and you have to explicitly allow updates as well as inserts, so a `update: function(userId, doc, fieldNames, modifier)){ return true;}` needs to be in your allow object as well 2) Yes, that update code should correctly update the schema he described 3) Be sure to update it like `Providers.update(doc._id, {...})` from the client. You client code should generally not use objects as selectors on the client side. – Thaum Rystra Apr 24 '15 at 06:35
  • I did have the update allower also. But, Thanks! It works wonderfully. Appreciate your help. – Abhishek Sunku Apr 24 '15 at 07:11