Open lloydtabb opened 8 months ago
Yeah, currently all except
does is delete state
from the fields, which doesn't work if you have a filter using that field... except
came from a time when we didn't really expect you to extend
a source multiple times.
It does seem like instead of removing it outright we could just mark it as inaccessible, which I think would solve this issue. @mtoy-googly-moogly
Renaming except
to private
is an interesting idea, but we do have the same issue with accept
:
source: a1 is airports extend {
where: state='CA'
} extend {
accept: code
}
run: a1 -> {select: *}
We should consider a new strategy for limiting fields...
source: a1 is airports extend {
where: state='CA'
} extend {
private: state // makes an existing field private
private dimension: my_field is ... // make a new field which is private
// also probably need some form of "accept"... maybe something like
private: * { except: state }
// or perhaps we just keep
accept: state // to mean make everything except state private
// only semi-related, but add tags to an inherited field
dimension:
# new_tag
my_field
}
except/accept are filters and the are processed super early in the construction of a source, and they are implemented using the same mechanism, so lloyd's hope that this would be quick or easy is dashed.
it was also just a quick hack, i knew that editing the namespace would someday be important, but we didn't really know enough to do much so it is kind of a placeholder for namespace management. it isn't a beautiful and prefect design.
There is a discussion brewing on namespace management, this should get folded into that. I could see that when we are done and have public/protected/private accept/except could become a deprecated feature which was implemented by filtering with private instead of removal
I'm not sure we have the concept of 'except' right. Consider:
Right now we blow up. The goal here is to use
state
to perform a filter but not have it available on subsequent sources. Do we want something like private instead?