Problems with schema other than the default 'public'

[fabioselau077]

Hello, is there any known issue with customizing the schema? I needed to leave it in a different schema than the default public one, but apparently it converts to "core."taggables" instead of "core.taggables" which ends up breaking all the queries.

For example:
SQLSTATE[42P01]: Undefined table: 7 ERROR: missing FROM-clause entry for table "core" LINE 1: select * from "core"."taggables" where "core"."taggable_id" ... ^ (Connection: pgsql, SQL: select * from "core"."taggables" where "core"."taggable_id" = 7 and "core"."taggable_type" = Models\News)

By modifying the function below I can now resolve the issue, but I don't know if the best way would be to open a PR, or create a new key in the 'schema' config.

HasTags.php

public function getTaggableMorphName(): string
    {
        $name = config('tags.taggable.morph_name', 'taggable');

        return str_contains($name, '.') ? last(explode('.', $name)) : $name;
    }

[zigzagdev]

@fabioselau077

I agree the core problem is that morph_name is being used for two different concerns:

1. The relationship column prefix (e.g. taggable_id) .
2. Helping Eloquent resolve table ownership in the query.

With a schema-qualified value like core.taggables, the query builder can interpret core as an alias, which leads to the missing FROM-clause error you’re seeing.

Since this is currently a Discussion (and I can’t open a PR directly from here), I propose we track it as an Issue / change request with a concrete implementation plan:

• keep morph_name strictly as a simple prefix (no dots)
• add an optional schema (or table_qualifier) config key
• only combine schema + table name when referencing the table, not when building morph column names

Hope this helps.