Please comment on the Jira if you have an opinion :)
On Monday, March 29, 2021, 10:48:34 AM PDT, la...@apache.org
wrote:
Filed https://issues.apache.org/jira/browse/PHOENIX-6433
We can discuss there.
In the end, IMHO, placing columns in distinct column families is a physical
optimiz
Filed https://issues.apache.org/jira/browse/PHOENIX-6433
We can discuss there.
In the end, IMHO, placing columns in distinct column families is a physical
optimization, not a logical construct...
Very much like indexes. And just like indexes these physical optimizations
should not leak into the
I agree that having identical column names is generally a pain, and I have
no problem with disallowing them in statically defined Phoenix columns, as
long as the views on HBase tables and the dynamic column features are not
affected.
We may or may not want to add a property to override it (with th
Viraj, yeah similar discussion.
Istvan, good point. Of course you cannot guard against what folks do at the
HBase level, and we should still allow that. Just like in PHOENIX-6343.
But we could disallow creating new tables like this in Phoenix, also like
PHOENIX-6343.
I just think that causes m
Somewhat similar discussion we had on PHOENIX-6343 and why the duplicate
column check was restricted to default CF only.
On Sat, 27 Mar 2021 at 10:42 AM, Istvan Toth
wrote:
> The first thing that comes to my mind is that this would limit
> functionality when defining views on existing raw HBase
The first thing that comes to my mind is that this would limit
functionality when defining views on existing raw HBase tables (though
aliasing the columns may solve that)
Another thing to consider is how this would affect dynamic column use cases
for either native Phoenix tables of views on HBase t
