Thanks Dawid and other people. +1 for using option #3 for 1.9.0 and go with option #1 in 1.10.0.
Regarding Xuefu's concern, I don't know how necessary it is for each catalog to deal with tmpView. I think Catalog is different from DB, we can have single concept for tmpView, that make user easier to understand. Regarding option #2, It is hard to use if we let user to use fully qualified name for hive catalog. Would this experience be too bad to use? Best, Jingsong Lee ------------------------------------------------------------------ From:Kurt Young <ykt...@gmail.com> Send Time:2019年7月23日(星期二) 17:03 To:dev <dev@flink.apache.org> Subject:Re: [DISCUSS] Support temporary tables in SQL API Thanks Dawid for driving this discussion. Personally, I would +1 for using option #2 for 1.9.0 and go with option #1 in 1.10.0. Regarding Xuefu's concern about option #1, I think we could also try to reuse the in-memory catalog for the builtin temporary table storage. Regarding to option #2 and option #3, from user's perspective, IIUC option #2 allows user to have simple name to reference temporary table and should use fully qualified name for external catalogs. But option #3 provide the opposite behavior, user can use simple name for external tables after he changed current catalog and current database, but have to use fully qualified name for temporary tables. IMO, option #2 will be more straightforward. Best, Kurt On Tue, Jul 23, 2019 at 4:01 PM Aljoscha Krettek <aljos...@apache.org> wrote: > I would be fine with option 3) but I think option 2) is the more implicit > solution that has less surprising behaviour. > > Aljoscha > > > On 22. Jul 2019, at 23:59, Xuefu Zhang <xu...@apache.org> wrote: > > > > Thanks to Dawid for initiating the discussion. Overall, I agree with Timo > > that for 1.9 we should have some quick and simple solution, leaving time > > for more thorough discussions for 1.10. > > > > In particular, I'm not fully with solution #1. For one thing, it seems > > proposing storing all temporary objects in a memory map in > CatalogManager, > > and the memory map duplicates the functionality of the in-memory catalog, > > which also store temporary objects. For another, as pointed out by the > > google doc, different db may handle the temporary tables differently, and > > accordingly it may make more sense to let each catalog to handle its > > temporary objects. > > > > Therefore, postponing the fix buys us time to flush out all the details. > > > > Thanks, > > Xuefu > > > > On Mon, Jul 22, 2019 at 7:19 AM Timo Walther <twal...@apache.org> wrote: > > > >> Thanks for summarizing our offline discussion Dawid! Even though I would > >> prefer solution 1 instead of releasing half-baked features, I also > >> understand that the Table API should not further block the next release. > >> Therefore, I would be fine with solution 3 but introduce the new > >> user-facing `createTemporaryTable` methods as synonyms of the existing > >> ones already. This allows us to deprecate the methods with undefined > >> behavior as early as possible. > >> > >> Thanks, > >> Timo > >> > >> > >> Am 22.07.19 um 16:13 schrieb Dawid Wysakowicz: > >>> Hi all, > >>> > >>> When working on FLINK-13279[1] we realized we could benefit from a > >>> better temporary objects support in the Catalog API/Table API. > >>> Unfortunately we are already long past the feature freeze that's why I > >>> wanted to get some opinions from the community how should we proceed > >>> with this topic. I tried to prepare a summary of the current state and > 3 > >>> different suggested approaches that we could take. Please see the > >>> attached document[2] > >>> > >>> I will appreciate your thoughts! > >>> > >>> > >>> [1] https://issues.apache.org/jira/browse/FLINK-13279 > >>> > >>> [2] > >>> > >> > https://docs.google.com/document/d/1RxLj4tDB9GXVjF5qrkM38SKUPkvJt_BSefGYTQ-cVX4/edit?usp=sharing > >>> > >>> > >> > >> > >
