Add extra explanation about dbs in namespaces docs #3420
Conversation
| @@ -10,11 +10,13 @@ An example of a namespace is the RDMS's `schema` concept. Some common use cases | |||
|
|
|||
| The Airbyte Protocol supports namespaces and allows Sources to define namespaces, and Destinations to write to various namespaces. | |||
|
|
|||
| The most common use of namespaces is in the context of database sources and destinations. For databases, generally, a namespace is synonymous with a schema. In the Postgres source, for example, the table `public.users` would be represented in Airbyte as `{ "namespace": "public", "name" "users" }`. If replicating this into a destination that supports namespacing, by default, records from this table would be replicated into `public.users` in the destination. | |||
There was a problem hiding this comment.
The more I see questions about it the least good I feel about how we've forced a decision, because we don't know what users want here and right now we make an assumption.
if I enumerate the two cases:
- I want my namepace.table to show as a namespace and table in my destination (generally makes sense for databases)
- I want my namepace.table to show as a table in my destination in a namespace that I decided (generally makes sense for datawarehouses)
Right now we just always go for the first solution which doesn't seem right. Do you share the same feeling?
There was a problem hiding this comment.
Yeap. Agree with you on the two options. I'm less sure on the database/warehouse split. From the users I've spoken to, wanting to replicate into a custom namespace/schema seems more arbitrary and related to legacy reasons than anything else e.g. existing pipeline already expects this.
When @cgardens and I discussed, it was very much to get something out that solves the problem of clashing names, get feedback and adjust. Maybe we can decide we've heard enough and can prioritise making destination namespace configurable?
What