I am pretty sure this closes #5628

There's something off with the PropertiesModelBuilder in the SqlDelightPlugin. The PropertiesModelBuilder takes in a collection of SqlDelightDatabase, however this is done for every project this plugin is applied to. It also seems to register the PropertiesModelBuilder on each project, potentially with a different collection of databases. So when the Gradle tooling queries for a model, it may not have the correct databases set for the specific project.

There's something off with the PropertiesModelBuilder in the SqlDelightPlugin. The PropertiesModelBuilder takes in a collection of SqlDelightDatabase, however this is done for every project this plugin is applied to. It also seems to register the PropertiesModelBuilder on each project, potentially with a different collection of databases. So when the Gradle tooling queries for a model, it may not have the correct databases set for the specific project.

AFAIK , the Gradle Tooling will be run for each Gradle project. So the IntelliJ sync should also be run isolated for each Gradle project.
But the IDEA plugin does not need any module dependencies at all, it just needs the sqldelight files from the other project.

I will rewrite the sqldelight Gradle plugin to support project isolation today and also will change the SqlDelightPropertiesFile. This file is currently used as Gradle task input and as Idea model, but that's problematic due the same reason you mention.

AFAIK , the Gradle Tooling will be run for each Gradle project

Yes, but the problem is with how the builder is registered. It's done so each time the plugin is applied, which can be multiple times, when it should only be registered once. The model builder provides the Project object in the buildAll() function to perform any project specific actions, such as grabbing the registered extensions.

it just needs the sqldelight files from the other project.

If this is the case, we may not even need the model builder at all. If we can add the sqldelight files as a source set via Gradle, that can be queried from the DataNode in the IDEA plugin after a sync is completed.

If we can add the sqldelight files as a source set via Gradle, that can be queried from the DataNode in the IDEA plugin after a sync is completed.

Do you mean a Gradle SourceDirectorySet? That's the direction I want to rewrite the sqldelight Gradle plugin.

Do you mean a Gradle SourceDirectorySet? That's the direction I want to rewrite the sqldelight Gradle plugin.

Yep! I think that will expose the files to the IDEA plugin, which we can then query for. Just out of curiosity, is the only place to expect the sqldelight files in the directory sqldelight under the main or similar folder?

Just out of curiosity, is the only place to expect the sqldelight files in the directory sqldelight under the main or similar folder?

Yes, commonMain or just main.

Yes, commonMain or just main.

If this is the case, we can get the path to this directory without adding it as a source to Gradle via the ContentRootData object in IntelliJ, which would contain the sources root path (which contains the src and resources directory). However, if this path can be changed, it'll need to be queried from Gradle via the Tooling API then.