0

We have an entity "robot".

Each robot has a start point, and current position, and other attributes like name, model...

Position is a http://geojson.org/ Point, and have more attributes, like slope_level and terrain.

We want to use geo queries, in order to query the robot position (and start point), so we need an index 2dsphere (as explained in this question this question).

Approach to the problem

Using Python-Eve, design a domain like:

DOMAIN = {
 'robot': {
  'item_title': 'robot',
  'url': 'robot',
  'schema': {
      'name': {
        'type': 'string',
        'required': True,
      },
      'start_point': {
        'type': 'objectid',
            'data_relation': {
                'resource': 'geopoints',
                'field': '_id',
                'embeddable': True
            }
      },
      'current_point': {
        'type': 'objectid',
            'data_relation': {
                'resource': 'geopoints',
                'field': '_id',
                'embeddable': True
            }
      }
  }
 },
 'geopoints': {
  'item_title': 'geopoints',
  'url': 'geopoints',
  'schema': {
      'terrain': {
        'type': 'string',
      },
      'slope_level': {
        'type': 'string',
      },
      'location': {
            'type': 'point'
      }
  }
 } 
}

In this case we have two collections, one with the geopoints and another with the robots. The geopoint has its "location" 2dsphere index, in order to run geojson queries.

If we want to create a new robot, we need to create first the geopoint "start_point", and then create the robot, sending as parameter the geopoint ID.

Is there a way to send in the same request a robot containing the start_point embedded object, and then tell Python-Eve to take the "start_point" new object, create a geopoint with this data, and link the start_point ID to the robot? (I know this can be done manually if you do it from the scratch, but I want to know if it is possible using the Python-Eve framework).

Is it a bad design and I need to have only one collection with the start_point embedded as object, and not as a standalone collection? (so in the same request we have our object ready).

Is there any pro/con on any of the approach?

Community
  • 1
  • 1
MTG
  • 551
  • 3
  • 14

1 Answers1

1

I'd say that splitting a single robot data into two collection would eventually make sense if your geopoints are somehow going to be re-used by other robots/resources, which seems unlikely.

Even then however, given the (very) little advantage you would get in terms of reduced storage/index space, I wonder if that makes any sense at all as you can query for your geopoints/terrain/etc. even if that kind of data is stored with each robot (you can still find all robots located at the same location). Also, consider the performance penalty you are going to suffer because of the double embedding you are adding at the robot endpoint.

So the question really is, will the added complexity inducted by splitting your robot data into two collections be really worth it?

Nicola Iarocci
  • 6,606
  • 1
  • 20
  • 33
  • Very useful answer!! I have been testing, and you have reason, the extra complexity that I need to handle if I have two different collections it is not worth it. Thanks! – MTG Mar 08 '16 at 08:06