Thanks Ryan and Daniel for the context. I'm OK that the server provides a separator via config endpoint. Just want to dig a bit more, it does provide more flexibility for the separator, but why do we need this flexibility? Looks like the only benefit is to reconstruct the namespaces. What's the use case of reconstruction? We may talk about it in tomorrow's meeting.
Thanks Eduard for the PR. Yufei On Tue, Aug 6, 2024 at 3:10 AM Eduard Tudenhöfner <etudenhoef...@apache.org> wrote: > It's probably best to make this configurable rather than changing the > separator in the spec. The server can communicate to the client which > namespace separator should be used (via a config override), but still needs > to support *%1F* as a fallback. I've opened #10877 > <https://github.com/apache/iceberg/pull/10877> to address this. > > @Robert: Old clients are already broken with *%1F* so we won't be able to > avoid an old client failing with a 4xx. Introducing a new endpoint that > takes a different namespace separator won't fix the issue for old clients > either, since those clients won't know anything about that endpoint. > > > On Mon, Aug 5, 2024 at 7:07 PM Daniel Weeks <dwe...@apache.org> wrote: > >> I would agree with adding either a server side (config override) or >> client side control (query param with `?delim=.`) as it will be >> compatible with the current v1 endpoint. >> >> In the future we could introduce a v2 endpoint(s), but I would want to >> wait for OpenAPI 4 because they address this by allowing multi-segment >> pathing via URI templates in RFC 6570 >> <https://datatracker.ietf.org/doc/html/rfc6570>, which is the original >> way we wanted to represent namespaces, but it wasn't supported (e.g. >> .../{+namespaces}/tables/{table}). I doubt it's really worth the effort >> though, so I feel like a configurable delimiter makes the most sense. >> >> -Dan >> >
