Bug: unknown variant Polygons

[rushmorem]

Describe the bug

Selecting a record that contains a MultiPolygon crashes the database.

Steps to reproduce

Run the following documented query:

UPDATE university:oxford SET locations = {
	type: "MultiPolygon",
	coordinates: [
		[
			[ [10.0, 11.2], [10.5, 11.9], [10.8, 12.0], [10.0, 11.2] ]
		],
		[
			[ [9.0, 11.2], [10.5, 11.9], [10.3, 13.0], [9.0, 11.2] ]
		]
	]
};

Select the record or export the database:

SELECT * FROM university:oxford;

The database crashes with the following error message:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Syntax("unknown variant `Polygons`, expected one of `Point`, `Line`, `Polygon`, `MultiPoint`, `MultiLine`, `MultiPolygon`, `Collection`")', lib/src/sql/value/value.rs:97:60

Expected behaviour

Selects should return the record successfully and exporting should work as expected. I have already identified the source of the bug and will prepare and submit a pull request shortly.

SurrealDB version

surreal 1.0.0-beta.7 for linux on x86_64

Contact Details

No response

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[tobiemh]

Hi @rushmorem , I've got the fix for this if you want me to push it up...?

[tobiemh]

I've found another issue, and am finishing a fix for this too (and adding some tests)...

[rushmorem]

Hi @tobiemh, it's OK take your time. It's just something I ran across while trying the SQL queries on the website.

[tobiemh]

Hi @rushmorem thanks for finding this bug 👏 !

[rushmorem]

It's my pleasure. Thank you so much for building this awesome database and open sourcing it!

[rushmorem]

@tobiemh While we are still on the topic of geometry types, are you interested in supporting more formats for latitude and longitude? For example the ones listed in this crate?

[tobiemh]

Definitely could look into supporting lat/lon degress, and the like. We would need to write it in the parser (as opposed to defer to the that crate though, as that will be more performant. Similar to how we are parsing datetimes/durations...

[tobiemh]

@rushmorem ☝️

[rushmorem]

OK, noted. This is not something I have a use for right now though. I just thought you might be interested. If it's something you need soon though, I will be happy to look into it.

[tobiemh]

@rushmorem could you add a separate feature request for it by any chance?

[rushmorem]

Sure! No problem.

[rushmorem]

Done

[Adithya2907]

@rushmorem @tobiemh has this issue been resolved? I tried to recreate the same, and the server crashed, giving the same error message.
Attaching a screenshot of the server logs.

[rushmorem]

@Adithya2907 Yes, it's fixed on main.

> UPDATE university:oxford SET locations = {
        type: "MultiPolygon",
        coordinates: [
                [
                        [ [10.0, 11.2], [10.5, 11.9], [10.8, 12.0], [10.0, 11.2] ]
                ],
                [
                        [ [9.0, 11.2], [10.5, 11.9], [10.3, 13.0], [9.0, 11.2] ]
                ]
        ]
};
[{"time":"246.85µs","status":"OK","result":[{"id":"university:oxford","locations":{"type":"MultiPolygon","coordinates":[[[[10.0,11.2],[10.5,11.9],[10.8,12.0],[10.0,11.2]]],[[[9.0,11.2],[10.5,11.9],[10.3,13.0],[9.0,11.2]]]]}}]}]
> SELECT * FROM university:oxford;
[{"time":"105.191µs","status":"OK","result":[{"id":"university:oxford","locations":{"type":"MultiPolygon","coordinates":[[[[10.0,11.2],[10.5,11.9],[10.8,12.0],[10.0,11.2]]],[[[9.0,11.2],[10.5,11.9],[10.3,13.0],[9.0,11.2]]]]}}]}]

v1.0.0-beta.8 won't have this issue.

[Adithya2907]

Yes, it's working on main. Thanks!