switch long and lat for geopoint type

[b-admike]

Description

MySQL expects reverse order of latitude and longitude from the way we use it in LoopBack, so switch the order when saving and loading Point spatial type we use for Point/GeoPoint.

Related issues

connect to #269
connect to https://github.com/strongloop-internal/scrum-apex/issues/239

Checklist

• New tests added or existing tests modified to cover all changes
• Code conforms with the style
  guide

[kjdelisle]

@bajtos Are we okay to merge this? I've opened the 5.x-beta branch as a way to land breaking changes but keep them off master for the time being.

[bajtos]

In the past, when we started to work on a new semver-major version, we created a new branch for the "latest" (4.x in this case) and kept "master" for the work on the upcoming major version. This way the git commit history remains linear. OTOH, when you fork off 5.x-beta branch and then merge it back to master later, then you will have two parallel lines in master history. There is also higher chance of getting merge conflicts, because by the time you merge 5.x-beta back into master, there may be other commits on master that are in conflict with 5.x-beta work.

Here is the description of the process we used for LoopBack 3.0: link to gist, see also our internal https://github.com/strongloop-internal/scrum-loopback/issues/601

Last but not least: we need to consider implications for long-term support, as described in http://loopback.io/doc/en/contrib/Long-term-support.html The important practical part is to ensure that each branch we are actively publishing from (3.x, 4.x, etc.) has a unique npm tag, and the tag "latest" is used by the branch containing the stable GA version. For example, strong-remoting's master branch is publishing "3.x" versions tagged as "latest", while the 2.x branch is publishing "2.x" versions tagged as "lts". The section [Publishing pre-release versions] in my gist contains additional information.

This is the process we used in LoopBack, it worked pretty well for us IMO. Of course, feel free to choose a different process if it works better for your squad/team.

[bajtos]

See npm/npm#6778 for an explanation why we need different npm tags for different release lines.

[b-admike]

I believe the new test was passing with the old implementation too, because the (wrong) order was used both for loading and saving. It would be nice to have a test that actually fails in the old implementation, I think it has to invoke custom SQL command using MySQL's Point features.

@bajtos PTAL. I've added more checks which make use of MySQL's Point functions and would fail in the old way we saved and loaded the GeoPoint datatype.

[bajtos]

I don't see any obvious problems. LGTM (FWIW).

[bajtos]

FWIW, we use the following pattern in other LoopBack projects - it produces more helpful failure messages:

- assert.ok(!err);
+ if (err) return done(err);

[kjdelisle]

@b-admike Before this merges, don't forget to change the target branch based on your discussion with @bajtos, and to make sure you've rebased accordingly!