filesystem destionation doesnt support model

[djudjuu]

dlt version

1.20.0

Describe the problem

it should not be included in supported destinations, because we can't make assumptions while writing about the client /conncetion that will read it (schema etc)

Expected behavior

No response

Steps to reproduce

use data quality checks with fs destination and check file endings

Operating system

Linux

Runtime environment

Local

Python version

3.13

dlt data source

No response

dlt destination

No response

Other deployment details

No response

Additional information

[sh-rp]

@djudjuu from the text in the ticket I cant figure out what the problem is, could you explain?

[djudjuu]

tldr: model files can be cross schema but the sql-client created to read the fs is one-schema only.

here is the issue that surfaced it:
data-quality-checks , were not working for filesystem destinations.
the problem was that the checks are transformations that were executed lazily (because if data and destination are on the same filesystem) so were just writing a model file.
if loader file format is .model no data gets written to the filesystem, because the FilesystemLoadJob just copies the file over. On sql-destinations model files are loaded with class ModelLoadJob which exectues the sql.

the sql-client that gets created for the filesystem is one-schema only, so when looking for the dq-checks in the dq-schema it couldnt find the tables referenced by the model

so the general problem, I tohugh, was that the model file doesnt store what schema it was referencing (or targeting).

so I thought it make sense to remove model from destination capabilites, but actually it gets complicated when athena or some other destiatnio use filesystem as staging (even though model-jobs are directly executed ( i think) and never touch staging.
rudolfix then stated that it was getting too complicated to account for this and just make the transformation-logic execute eagerly when filesystem is detected (see here: #3473 (review))