Closed armsepehr closed 1 year ago
Ah, nice-- this is a good idea.
Why not just embed the contents of the meta
dictionary in the formatting context so you could do e.g. s3://my-bucket/{folder2}/{name}.{suffix}
w/o the extra boilerplate? Are you worried about a naming conflict?
I think it's better to distinguish between the variable inside and outside the meta variable; however, this is a good idea to simplify the variable inside the f-string compare to directly referencing such assource.meta["folder2]
. What you said has another advantage and the previous test already passed to reference name
, schema
and identifier
. Please clarify your suggestion according to address a variable inside the f-string.
I was thinking like this (the test illustrates how it would look): https://github.com/jwills/dbt-duckdb/pull/130
Understood. It works as far as we don't have naming conflict. In the other side, I think what you said is more convenient and easy to reference the variable. Thanks.
I am interested in using external_location f-string with several variable but only
name
,indicator
andschema
are known in the f-string.Additionally, I don't want to overwrite the external_location for each table name. In this regard, I suggest to improve the f-string in real format name such as below:
In this case, the
indicator
should be addressed thesource.indicator
. I can do it myself, but please clarify that do you have any suggestion to improve this? I have identified the problem induckdb/relation.py
and send the PR to you, but as far as I'm not sure that you're agree with change I didn't modify the README. Additionally, the test should be improved in this regard, so I can do it myself after your suggestion.