Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
So, I was wrong when I initially looked at this PR, this adds variable
updates to the resolver. Should we perhaps separate parsing assignments (e.g.
move `StellarAssignment.from` into the language
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
@ottobackwards And yet this discussion primarily relates to whether the
assignment operation as defined in Enrichment should be unified with the
assignment operation being added to core
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
also @mattf-horton, those other things, to be generally useful and not
restrictive and assumptive of the host's use cases would have to be generalized
_so_ much, I think from an api pov would
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
As far as `hosting`.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
So, I would say then that we restrict to ONLY core at the moment. And then
we start creating interfaces and other api surfaces ( most likely extracted
from what we have ) as a follow on.
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
@ottobackwards , that's inarguably true. We can define the language to be
just the Stellar Core. We could also define it to include at least some of
those very useful other things, which
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
the details of how we configure transforms and enrichments, and organize
the stellar statements etc, are not required to implement or host stellar.
---
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
> I think we need to keep everything in it's separate pile. We have people
asking to host in not metron as recently as today.
My interpretation is that, in order to enable hosting
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
I vote to get rid of `:=` if we want to make it uniform.
I'll also straighten the scope stuff out etc. the whole nine yards if we
want to do that. I think that might make this a
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
If one insists that ':=' in Enrichments is a Metron add-on not Stellar,
that is equivalent to stating that Enrichment doesn't use Stellar but rather a
custom DSL derived from Stellar. The xml
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
the top level 'scope' being passed in kind of as it is now.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
the scope should be managed by the StellarExpression as a separate stack of
linked scope nodes and not in the resolvers.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
@mattf-horton
> As for := vs =, it's not so terrible to have both as exact synonyms. This
gives you both your preferred aesthetics and backward compatibility.
Not to keep harping
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
@nickwallen Yes, you are absolutely correct. Right now we do not have an
approach to take a list of stellar expressions that are assignments, a variable
resolver, a function resolver and execute
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
> @cestella: No, both the REPL and enrichments use the same method of
assignment, the StellarAssignment class. It's just that assignment in stellar
is available in multiple places.
Ah,
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
I am not opposed to changing the resolvers, or continuing work as it comes
out of this discussion
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
@nickwallen pending this discussion yes, it just adds the capability to the
language and stellar common, but not to _*Metron*_.
As stated in the PR description:
> This PR is
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
@nickwallen No, both the REPL and enrichments use the same method of
assignment, the `StellarAssignment` class. It's just that assignment in
stellar is available in multiple places.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
> @ottobackwards : This is opt-in for the resolvers. The
MapVariableResolver does NOT support update, so there is no change to
Enrichment, Parsers, Profile, and Shell ( beyond what has been
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
OK,
The others can comment, but I think proper scope would be implemented
within the execution of the call stack, not arbitrarily by the resolvers. Each
resolver should be a 'scope'
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
> @cestella: No, that's not correct. Stellar enrichments can contain :=.
Consider the enrichments here in one of our use-cases. Enrichments can either
take a map of enrichments
Thanks
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
So a bunch more comments came in while I was writing the above. Nick's
comment about enrichments using assignment already of course modifies my
comment about Profilers, etc. Just making it
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/687
As a professed language nut, when you mention the word "variable", I think
"scope". And it seems to me that by placing the responsibility for variable
assignment/update in the
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
@nickwallen No, that's not correct. Stellar enrichments can contain `:=`.
Consider the enrichments
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
@cestella @nickwallen
I have changed stellar assignment to cover the := already. I think it
will continue to work.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
> @cestella: What about users with existing stellar enrichments using :=
...
Oh, and one clarification. No users will have production code (like an
enrichment) that uses `:=`. That
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
hah, well @nickwallen, laziness is often a good trait in a developer.
Honestly, I am ok with *not* migrating here in favor of more intuitive
approaches. I chose `:=` because I needed the
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
> @cestella Migration, sadly sometimes, is also part of user experience. :)
Very true. That's why I offered up the ["Alternative
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
Yeah, I'm totally cool with going with `=`, but I will point out one snag.
What about users with existing stellar enrichments using `:=`, would we provide
a migration path beyond saying, "Hey,
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/687
I have not looked at the code yet, but wanted to comment on the assignment
discussion. IMO focusing on user experience is the way to go. To that end...
* We should use `=` because that
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
also, we aren't consistent, in some places ( transformations ) we use the
configuration logical structure to imply assignment, in enrichment it is `:=`,
but those are configuration mechanisms
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
By punt you mean leave this implementation that doesn't implement update in
the resolvers?
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
Agreed, this is a POV issue. Though from the user perspective they aren't
distinguishing between "this is in the REPL" vs "this is in the enrichment
topology", so I think we do need to manage the
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
POV issue I think. Stellar has the LANGUAGE ( grammar ), the default
implementation, and the 'host' execution mechanics.
`:=` is part of the host execution mechanics.
The
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/687
well, `:=` is in the shell and also in the enrichment configuration (see
[here](https://github.com/apache/metron/tree/master/metron-platform/metron-enrichment#stellar-enrichment-configuration).
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
@cestella also: := is in the shell not the language. The mechanics of
what is LANG and what is MACHINE is part of the issue.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
I just removed the conflicts and changed StellarAssignment to account for
this
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
Reviewer Note: Would a default method on the interface be better for
update()?
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
@cestella
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
It is fair to say that this PR is more for conceptual review than anything
else.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
should be set @JonZeolla
---
Github user JonZeolla commented on the issue:
https://github.com/apache/metron/pull/687
Is this ready for review? If so, can you deconflict?
---
42 matches
Mail list logo
