Maybe it can reuse some bits of Kotlin package prefix like in screenshot below:

It is pretty much readable and is easier to navigate in non-IDEs.

After some testing, it would be best to setup package prefix for every source folder, for example:

sqldelight {
    database("Database") {
        packageName = "$group.database"

        // OLD behaviour
        sourceFolders = setOf("migrations", "queries")

        // NEW behaviour
        sourceFolders = mapOf(
            "migrations" to "$group.database.migrations",
            "queries" to "$group.database.queries",
        )

        deriveSchemaFromMigrations = true
        dialect(libs.sqldelight.sqlite.dialect)
    }
}

Or can you came up with another, better solution? I can try to make a PR, but want to know what you authors think about this.

The more I am thinking about it the more wierd the current behaviour without the configuration feels.

For example, when deriveSchemaFromMigrations = true, it is pretty natural to look for the migration files in folder named migrations or something like this. But when generated, the basic data classes of tables are then located in package xx.yy.zz.migrations which is not natural.

I would expect importing those classes from package named something like xx.yy.zz.tables. The temporary solution is to rename migrations folder to tables, but then user is looking for migrations in "tables" and there is almost always much more than just tables.

The second is current behaviour is against Kotlin's own coding conventions about directory structure which suggest to omit common package prefix.

Directory structure

In pure Kotlin projects, the recommended directory structure follows the package structure with the common root package omitted. For example, if all the code in the project is in the org.example.kotlin package and its subpackages, files with the org.example.kotlin package should be placed directly under the source root, and files in org.example.kotlin.network.socket should be in the network/socket subdirectory of the source root.

@AlecStrong can you please help me figure out the best way to tackle this and validate my feelings about the current strucure?

I can then try to prepare a PR if we came to some conclusion.

Another way to solve this in simpler and backward compatible way is to split migration and queries configuration like this:

sqldelight {
    database("Database") {
        packageName = "$group.database"

        sourceFolders = setOf("sqldelight")
        sourcePackagePrefix = "$group.database.queries"

        migrationFolders = setOf("migrations")
        migrationPackagePrefix = "$group.database.tables"

        deriveSchemaFromMigrations = true
        dialect(libs.sqldelight.sqlite.dialect)
    }
}

Just throwing ideas here.

so theres a few things here, none of which I really want to solve with extra configuration:

• I've never seen a kotlin project omit the common package name, I'm not going to change our behavior to support that.
• the next release will display these better in the IDE so the admittedly disorganized look of things right now will instead one to one resemble kotlin packages.
• I think having an optional configuration specifically for the package name of the schema could make sense, but that is essentially what the packageName property is right now.
• Ultimately I think packages are more important for an organized directory structure. The IDE, auto import, and stuff like spotless means that coding in 2023 package names are barely important practically except for avoiding class conflicts.

@hfhbd has also been talking about this and might have more takes on this but for now my plan is to better document the existing stuff, and then potentially iterate on how the schema is packaged if you're deriving from migrations.

essentially better document the current behavior, which is (or should be if not currently):

all files just go to the package for their relative folder structure to the source root (for derived migrations, it is the folder the CREATE statement is in). If the file is in the source root, apply the packageName gradle property prefix.

@AlecStrong with the new compact display in IDE, I am okay with this, thank you :)