Update object being refined and update docs - Refinements

[dsmdavidSCIL]

I found this that suggests that refinements are parsed (and the functional tests + sample refinement).

I have been trying with the provided example and the parsing does not fail; however, I don't think the behaviour is what I would expect: I would expect the end object to have only the base view, with each of the fields inside updated as per the layers of refinements. Instead, the object contains multiple views (the base view and each of the refinements).

I didn't find any reference in the docs to refinements, so maybe that is the intended behaviour.

e.g. input:

view_txt = '''
view: tickets {
  label: "foo"
}

view: +tickets {
  label: "baz"
}

view: +tickets {
  label: "bar"
}
'''
parsed = lkml.load(view_txt)

end_object = lkml.dump(parsed)

My expectation would be that 'end_object' is:

view: tickets {
  label: "bar"
}

Or, if that is not the end_object, that I could retrieve it from the parsed object (as the refinements are position dependant).

[joshtemple]

Hey @dsmdavidSCIL! Thanks for asking this question, it's a good one, and I'll make a note to document this better for the future.

One design choice I made with lkml, is that you should be able to parse lkml and then serialize it back to its original form (with the exception of whitespace and comments, when using simple parsing). If we were to resolve the base view with refinements like you've described, we wouldn't be able to serialize it back to its original form because we would lose the information that baz and bar come from a refinement.

I want to avoid adding any of Looker's actual higher-level "understanding" of LookML into this parser. It's a slippery slope, and I want the parser to be firmly rooted in "converting LookML into a Python data structure that can be navigated and altered." Resolving refinements is something Looker should do, but I don't believe it's something this parser should do.

In this case, I recommend you write some code to resolve the refinements yourself as I believe it's out of scope for the way the parser is intended to function. If it's not possible to do that without changes to lkml, please let me know!