sjwiesman commented on issue #8903: [FLINK-12747][docs] Getting Started - Table API Example Walkthrough URL: https://github.com/apache/flink/pull/8903#issuecomment-506360114 Thank you for taking a look @knaufk . > I would be in favor of simply adding this as an example to flink-examples-table without a maven archtype. Firstly, we already have quickstart modules to create program skeletons. Adding an additional option for the walkthroughs adds extra burden in terms of ongoing maintenance and might confuse users. I believe the best walkthroughs are the ones users can easily run and make small modifications to. In practice, this means we need an easy way to import the initial project into their IDE. If the code is in `flink-examples-table` it is non-trivial to extricate it from the rest of flink. This archetype is not meant to replace the quickstart archetypes in any way, and only serves as a way to quickly and easily create a new project with the right dependencies and initial set up for following along with the tutorial. We can make the `Setting up a Maven Project` more clear about what we are doing and direct users towards the generic quickstarts if they want to build their own projects. > Secondly, in my opinion, a "code walkthrough" should focus on explaining the code of an example so that I can easily follow it. I don't necessarily expect the utilities to bootstrap a new program here. (We should have a separate dedicated subsection in the "Getting Started" section for the quickstarts/project setup.) Again, not the intention but I take this to mean what I have is not clear enough. I would also support quickly moving [Application Development -> Project Build Setup](https://github.com/apache/flink/tree/master/docs/dev/projectsetup) to the getting started section with a nice introduction. This way it should be more clear to users that if they want to start a new project look here, and if they want a follow along look there. The fact that both these components use maven archetypes to facilitate their goals is just a coincidence. > Personally, I think, the example for a code walkthrough should be no-magic and I should be able to understand as much as possible as a new user. Here this means to go without the custom TableSource, which is not easy to understand and it is not clear why this can be a streaming and batch source at the same time etc.. Alternatively, one could simply read from a file of transactions (batch case) or read from a message queue (streaming case; maybe provide a minimal data generator). This would also go well with the future vision of "simply replace the source and your job turns into a streaming program", although we are not there yet. 1) This is not a dockerized environment and so I think we should avoid any external dependencies. 2) I should better explain that tables are logical views on top of external systems such as file systems or message queues but I don't see them as magic. > Do we also want to add SQL to this example (probably as a section in the end implementing the same business logic)? Currently, we don't plan to have dedicated "SQL Walkthrough". Do we need an SQL walkthrough at all? My thought was this would be just focused on the Table Api and we could do some sort of SQL walkthrough with the docker environment.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
