I'll take another look at the PR. My inclination is still to use uuids
to uniquify. I think that's worth the cost to the readability hit (I'm
OK reducing this down to 6-8 hex digits which will still give very low
chances of collisions, though it doesn't solve the first one). If
someone cares about
On Fri, Oct 20, 2023 at 11:35 AM Kenneth Knowles wrote:
>
> A couple other bits on having an expression language:
>
> - You already have Python lambdas at places, right? so that's quite a lot
> more complex than SQL project/aggregate expressions
> - It really does save a lot of pain for users
A couple other bits on having an expression language:
- You already have Python lambdas at places, right? so that's quite a lot
more complex than SQL project/aggregate expressions
- It really does save a lot of pain for users (at the cost of
implementation complexity) when you need to
Just want to bump this discussion again. I'm introducing Beam to other
developers at my Schrodinger now and the first (of hopefully many!)
developer has started migrating our internal workflows to Beam. As I
suspected though, he's complained about the iteration cycles spent from
using the same
On Fri, Oct 20, 2023 at 3:29 AM Jan Lukavský wrote:
> Yes, I'm aware that Beam is not defined in terms of runner convenience,
> but in terms of data transform primitives. On the other hand - looking
> at that from specific perspective - even though stateless shuffle does
> not change the data
This is your daily summary of Beam's current high priority issues that may need
attention.
See https://beam.apache.org/contribute/issue-priorities for the meaning and
expectations around issue priorities.
Unassigned P1 Issues:
https://github.com/apache/beam/issues/29076 [Failing Test]:
Yes, I'm aware that Beam is not defined in terms of runner convenience,
but in terms of data transform primitives. On the other hand - looking
at that from specific perspective - even though stateless shuffle does
not change the data itself, it changes distribution of data with
relation to
