Hi
thanks for the proposal and not abandoning this thread. This topic is very
important. I left some comments.
Thanks,
Łukasz
śr., 23 sty 2019 o 10:00 Etienne Chauchot napisał(a):
> HI guys,
>
> As part of our user growth, I'd like to revive this subject.
> I have sketched up a 2 pages
HI guys,
As part of our user growth, I'd like to revive this subject.I have sketched up
a 2 pages proposal on this:
https://docs.google.com/document/d/1eXt54ht0h7-pPbP-MJR0N5nzmxRRlAwbFod-LXI1x0A/edit?usp=sharing
Unfortunately I have no knowledge on IDE plugin developement. Does someone have
Hi guys,
To sum up what we said, I just opened this
ticket:https://issues.apache.org/jira/browse/BEAM-5849
Etienne
Le jeudi 18 octobre 2018 à 12:44 +0200, Maximilian Michels a écrit :
> Plugins for IDEs would be amazing because they could provide feedback already
> during pipeline construction,
Plugins for IDEs would be amazing because they could provide feedback
already during pipeline construction, but I'm not sure about the effort
required to develop/maintain such plugins.
Ultimately, Runners have to decide whether they can translate the given
pipeline or not. So I'm leaning more
Similar to how we have `validate()` on the Pipeline to check the
pipeline specification, dry-run would check the pipeline translation and
report errors back to the user.
Assuming that Runners throw errors for unsupported features, that would
already give users confidence that they will be
Hey Max, Kenn,
Thanks for your feedback !
Yes the idea was to inform the user as soon as possible, ideally while coding
the pipeline. It could be done with a IDE
plugin (like checkstyle) that is configured with the targeted runner; that way
the targeted runner conf is not part of
the pipeline
Yes indeed, your understanding is correct. This is what I had in mind.
PS: I have no idea on perf right now.
Etienne
Le mardi 16 octobre 2018 à 15:03 -0700, Rui Wang a écrit :
> Sounds like a good idea.
> Sounds like while coding, user gets a list to show if a feature is supported
> on
On Wed, Oct 17, 2018 at 3:17 PM Kenneth Knowles wrote:
> On Wed, Oct 17, 2018 at 3:12 AM Maximilian Michels wrote:
>
>> A dry-run feature would be useful, i.e. the user can run an inspection
>> on the pipeline to see if it contains any features which are not
>> supported by the Runner.
>>
>
>
On Wed, Oct 17, 2018 at 3:12 AM Maximilian Michels wrote:
> A dry-run feature would be useful, i.e. the user can run an inspection
> on the pipeline to see if it contains any features which are not
> supported by the Runner.
>
This seems extremely useful independent of an annotation processor
This is a good idea. It needs to be fleshed out how the capability of a
Runner would be visible to the user (apart from the compatibility matrix).
A dry-run feature would be useful, i.e. the user can run an inspection
on the pipeline to see if it contains any features which are not
supported
Sounds like a good idea.
Sounds like while coding, user gets a list to show if a feature is
supported on different runners. User can check the list for the answer. Is
my understanding correct? Will this approach become slow as number of
runner grows? (it's just a question as I am not familiar the
Sounds like a good idea. I don't think it will work for all capabilities
(e.g. some of them such as "exactly once" apply to all of the API surface),
but useful for the ones that we can capture.
On Thu, Oct 4, 2018 at 2:43 AM Etienne Chauchot
wrote:
> Hi guys,
> As part of our user experience
+1
it sounds like a good idea to me.
I would allow us to "automatize" our features coverage and give more
vision to our users.
Regards
JB
On 04/10/2018 11:43, Etienne Chauchot wrote:
> Hi guys,
> As part of our user experience improvement to attract new Beam users, I
> would like to suggest
Hi guys,
As part of our user experience improvement to attract new Beam users, I would
like to suggest something:
Today we only have the capability matrix to inform users about features support
among runners. But, they might discover
only when the pipeline runs, when they receive an exception,
14 matches
Mail list logo
