Database Table Does Not Exist

[SAB13711]

I have a database table that definitely exists in the postgres db, but i get this error:

2026-06-10 13:41:05.014 | {"sql": "SELECT * FROM gift_cards.gift_card WHERE created_by_email = %s AND is_deleted = 0 LIMIT %s OFFSET %s", "params": ["schalk@codeinfinity.co.za", 20, 0]} |  
-- | -- | --
  |   | 2026-06-10 13:41:05.014 | ^ |  
  |   | 2026-06-10 13:41:05.014 | LINE 1: SELECT * FROM gift_cards.gift_card WHERE created_by_email = ... |  
  |   | 2026-06-10 13:41:05.014 | 2026-06-10T11:41:05.014Z [ERROR  ] [4fce1b07b90404b98a2c649e0854c59b] PostgreSQL query failed: UndefinedTable: relation "gift_cards.gift_card" does not exist

[andrevanzuydam]

Fixed in v3.13.14 (published to PyPI, plus Packagist / RubyGems / npm — the fix shipped with full parity across all four Tina4 frameworks).

Root cause

Your table lives in a non-default PostgreSQL schema (e.g. gift_cards.gift_card). Tina4's introspection — table_exists(), get_tables(), get_columns() — hardcoded the public schema and matched the dotted name as one flat string. So plain reads worked, but create_table, migrations, and auto-CRUD couldn't see the table and reported it missing.

Fix

Introspection is now schema-aware on every affected engine:

• PostgreSQL — table_exists uses to_regclass() (honours the schema and search_path); get_columns filters by table_schema; get_tables lists every non-system schema and returns non-public tables schema-qualified.
• MySQL — schema = database; a qualified name checks that catalog, a bare name defaults to DATABASE().
• MSSQL — honours dbo.table; a bare name matches in any schema.
• SQLite — honours an ATTACH alias (extra.widget).
• Firebird — N/A (no schemas).

Verified

Against a live PostgreSQL 16 container with your exact shape:

table_exists('gift_cards.gift_card') -> True
get_tables()                         -> ['gift_cards.gift_card', 'gift_cards.transaction']
get_columns('gift_cards.gift_card')  -> 12 columns

Identical results confirmed in all four frameworks.

Reference a schema-qualified table by its qualified name (schema.table) in your model's table_name and introspection/migrations will now resolve it correctly. Please upgrade to 3.13.14 and let us know if anything's still off — happy to reopen if needed.