Hi Russel, Would this be a good candidate for a future version of the spec?
Thanks, Walaa. On Thu, Oct 10, 2024 at 3:50 PM Russell Spitzer <russell.spit...@gmail.com> wrote: > I still have an issue with representations not having explicit ways of > incorporating the catalog name, I'm thinking about our potential future > situation where we want to return a view for Fine Grained Access policies. > In that case won't the Catalog need to craft a representation that matches > the configuration of the engine? Doesn't this mean the client will have to > tell the Catalog what its local name is? > > On Thu, Oct 10, 2024 at 5:34 PM Daniel Weeks <dwe...@apache.org> wrote: > >> Hey Walaa, >> >> I recognize the issue you're calling out but disagree there is an >> implicit assumption in the spec. The spec clearly says how identifiers >> including catalogs and namespaces are represented/stored and how references >> need to be resolved. The idea that a catalog may not match is an >> environmental/infrastructure/configuration issue related to where they are >> being referenced from. >> >> If we think this is sufficiently confusing to people, I would be open to >> discussing an "unsupported configurations" callout, but I don't think this >> blocks work and am somewhat skeptical that it's necessary. >> >> -Dan >> >> >> >> On Thu, Oct 10, 2024 at 2:47 PM Walaa Eldin Moustafa < >> wa.moust...@gmail.com> wrote: >> >>> Hi Dan, >>> >>> I think there are a few questions that we should solve to decide the >>> path forward: >>> >>> ** Does the current spec contain implicit assumptions?* >>> I think the answer is yes. I think this is also what Ryan indicated here >>> [1]. >>> >>> ** Do these implicit assumptions make it difficult to adopt the spec or >>> evolve it in the correct way?* >>> I think the answer is yes as well. MV design discussions became quite >>> complicated because most contributors had a different understanding of the >>> spec compared to what it encodes as implicit assumptions (see this thread >>> for an example [2] -- there are a few more). This unaligned understanding >>> could possibly lead to inaccurate designs and potentially result in >>> unneeded further constraints or unneeded engineering complexity. >>> >>> ** What are the implicit assumptions (in an ambiguous way)?* >>> I do not think the answer is clear to everyone, even at this point. >>> There have been a few variations of those assumptions in this thread alone. >>> I think we should converge on a clear set of assumptions for everyone's >>> consumption. >>> >>> ** Should we add the assumptions explicitly to the spec?* >>> I think we definitely should. Adoption or extension of the spec will be >>> quite difficult if the assumptions are not clearly stated and are >>> interpreted differently by different contributors. >>> >>> Would be great to hear the community's feedback on whether they agree >>> with the answers to the above questions. >>> >>> [1] https://lists.apache.org/thread/s1hjnc163ny76smv2l0t2sxxn93s4595 >>> [2] https://lists.apache.org/thread/0wzowd15328rnwvotzcoo4jrdyrzlx91 >>> >>> Thanks, >>> Walaa. >>> >>
