Add support for geopoly Interface

[nikitadol]

Solves #2892

Questions and suggestions regarding implementation are welcome

More tests and perhaps an example will be added soon

[simolus3]

Awesome work with the sqlparser extension! I think we should consider moving the runtime mapping away from the core library to reflect that this is not something all databases support. The rest of this look great!

[nikitadol]

Regarding all your comments:
I tried doing this via CustomSqlType, which I put in package:drift/extensions/geopoly.dart, but there are a few problems:

• The only place where I can specify a different type of function columns and arguments is here:
  

  drift/drift_dev/lib/src/analysis/resolver/drift/sqlparser/mapping.dart

  Lines 153 to 155 in 78387a3

  	if (type.hint<IsGeopolyPolygon>() != null) {
  	return const ColumnType.geopolyPolygon();
  	}

• It is difficult to create a DartType (in this exact place) and then pass it to the CustomColumnType

I'm still thinking about a solution, I will be glad if you have any suggestions, since sqlparser cannot depend on drift_dev

Perhaps a mechanism is needed to allow modules to define types

[simolus3]

The only place where I can specify a different type of function columns and arguments is here:

I'm using the KnownDriftTypes utility to solve this. package:drift/src/drift_dev_helper.dart exports a bunch of classes which we'd like to resolve in drift_dev, we can then pick them up from there and turn them into InterfaceTypes. That library could also export the geopoly types.

I'm still thinking about a solution, I will be glad if you have any suggestions, since sqlparser cannot depend on drift_dev

But we only need to inject the actual custom type in drift_dev, right? Once the type hint is there it should be preserved by sqlparser.

[nikitadol]

I had to slightly change the use of KnownDriftTypes so as not to change many synchronous methods to asynchronous

Or is this not an option?

[simolus3]

I had to slightly change the use of KnownDriftTypes so as not to change many synchronous methods to asynchronous

I think this shouldn't be a problem. We need the known types for almost everything involving the driver, so we might as well preload it.

The failing test worries me a bit as loading more assets may degrade build performance, but since this is all coming from external packages that would invalidate the entire build either way, it shouldn't be a problem.
You can apply this patch to fix the test

diff --git a/drift_dev/test/backends/build/build_integration_test.dart b/drift_dev/test/backends/build/build_integration_test.dart
index d81f397f..e1828132 100644
--- a/drift_dev/test/backends/build/build_integration_test.dart
+++ b/drift_dev/test/backends/build/build_integration_test.dart
@@ -583,6 +583,8 @@ class MyDatabase {
       return everyElement(
         anyOf(
           isA<AssetId>().having((e) => e.extension, 'extension', '.json'),
+          // Allow reading SDK or other package assets to set up the analyzer.
+          isA<AssetId>().having((e) => e.package, 'package', isNot('a')),
           other,
         ),
       );

[simolus3]

I've added a simple test to drift to make sure the type is roughly doing what it's supposed to. This looks good to me now, but I want to merge #2939 first.

[nikitadol]

Thanks for helping
I also fixed some tests and added clarification to the documentation, since by default geopoly is not in the sqlite3_flutter_libs package

[simolus3]

LGTM, thanks! 👍