!describe SYSTEM.CATALOG is not returning IS_ROW_TIMESTAMP column.
But we do see this column from select statement:
select * from SYSTEM.CATALOG where TABLE_NAME=’TEST_TABLE_1’ AND
TABLE_SCHEM IS NULL AND TENANT_ID IS NULL ;
Thanks,
Arun
On Wed, Apr 20, 2016 at 1:37 AM, Ankit Singhal <ankitsingha...@gmail.com>
wrote:
> Hi Arun,
>
> Do you see 'IS_ROW_TIMESTAMP' column in SYSTEM.CATALOG, by doing
> !describe on system.catalog.
>
>
> if not,
> can you share the output of below command. As it seems SYSTEM.CATALOG was
> updated with timestamp greater v4.6 timestamp , and which stopping upgrade
> code to add a new column.
>
> scan 'SYSTEM.CATALOG', {RAW=>true}
>
>
>
> Regards,
> Ankit Singhal
>
> On Wed, Apr 20, 2016 at 4:25 AM, Arun Kumaran Sabtharishi <
> arun1...@gmail.com> wrote:
>
>> After further investigation, we found that Phoenix Upsert query
>> SYSTEM.CATALOG has IS_ROW_TIMESTAMP column, but PTableImpl.getColumn() is
>> failing with error:"Undefined column. columnName=IS_ROW_TIMESTAMP" . Does
>> this mean that PTableImpl is reading from cached entity of SYSTEM.CATALOG
>> before 4.6 upgrade?"
>>
>> We do see that clearCache() is being called for 4.7, and 4.7 upgrades
>> from ConnectionQueryServicesImpl class, but not for 4.6
>>
>>
>> Thanks,
>> Arun
>>
>> On Tue, Apr 19, 2016 at 10:22 AM, Arun Kumaran Sabtharishi <
>> arun1...@gmail.com> wrote:
>>
>>> James,
>>>
>>> To add more information on this issue, this happens in new phoenix views
>>> associated with brand new tables as well. So, this cannot be an
>>> upgrade/migration issue. Not figured out a specific way to reproduce this
>>> issue yet. Could you throw some ideas on what direction this problem could
>>> be approached from this point?
>>>
>>> Thanks,
>>> Arun
>>>
>>
>>
>
