MSSQL Geometry Point no longer working after 0.2.25

[Steffion]

Issue type:

[ ] question
[x] bug report
[ ] feature request
[ ] documentation issue

Database system/driver:

[ ] cordova
[ ] mongodb
[x] mssql
[ ] mysql / mariadb
[ ] oracle
[ ] postgres
[ ] cockroachdb
[ ] sqlite
[ ] sqljs
[ ] react-native
[ ] expo

TypeORM version:

[x] latest
[ ] @next
[x] 0.2.25 (or put your version here)

Steps to reproduce or a small repository showing the problem:

As the title says, the POINT entry in a MSSQL database with the Geometry column type is no longer working as of 0.2.25.

See logging between version as result:

0.2.25
INSERT INTO "barrack"("code", "location", "name") OUTPUT INSERTED."id" INTO @OutputTable VALUES (@0, geography::STGeomFromText(@1, 0), @2);

0.2.24
INSERT INTO "barrack"("code", "location", "name") OUTPUT INSERTED."id" INTO @OutputTable VALUES (@0, @1, @2);

Please notice the weirdly formatted SQL Query with parameters.
A fix would be great! Thanks for your support in advance.

[Steffion]

Seems like this was changed in the PR #5947

[Steffion]

For anyone else having this issue, I fixed it with adding the SRID to your Column decorator:
@Column({ type: "geography", srid: 4326 })

[waikuen2010]

Sorry for the trouble caused. The previous behavior for inputting geometry is using WKT without taking SRID into account. My PR is to add support for SRID option.

As a patch update, typeorm should not introduce any breaking changes to the package. I should definitely be more careful about this.

I know 4326 is adopted by many popular map solution. However, I can't find MSSQL documentation about the default value of SRID when not using the STGeomFromText function. I am not sure if it makes sense to set default value to 4326. Can you provide some official reference on this issue?

[Steffion]

@waikuen2010 thanks for the response.
Some guy explained here https://stackoverflow.com/a/378941/4726278 why you should use 4326 as default value.

As of MSSQL documentation, not sure.

[imnotjames]

Looks like this was fixed by #5947 - as such I'll close this issue out but we can definitely re-open it if the issue persists!