Hello!

Unfortunately there's no support in Native SQL API for table introspection.
You could use thin client since it's fairly lighweight.

Regards,

-- 
Ilya Kasnacheev

2018-05-24 23:50 GMT+03:00 Nick Pordash <[email protected]>:

> Hi Illya,
>
> Is this possible to get without having to resort to JDBC? For example, the
> Ignite SQL Java Apis?
>
> -Nick
>
>
> On Mon, May 21, 2018, 5:56 AM Ilya Kasnacheev <[email protected]>
> wrote:
>
>> Hello!
>>
>> Cache Configuration would only request its configuration at the time when
>> it was started. It will not be modified when DDL is issued.
>>
>> Yes, you can detect column changes, e.g. by using JDBC Metadata:
>> https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>>
>> Regards,
>>
>> --
>> Ilya Kasnacheev
>>
>> 2018-05-18 20:38 GMT+03:00 Shai N <[email protected]>:
>>
>>> I'm trying to detect in Java which fields in a cache are exposed to SQL
>>> by
>>> looking at
>>> "((QueryEntity)ignite.cache("cacheName").getConfiguration(
>>> CacheConfiguration.class).getQueryEntities().iterator().
>>> next()).getFields()".
>>> This accurately reflects a table's initial schema. However, changes made
>>> with "ALTER TABLE ADD COLUMN" and "DROP COLUMN" are not reflected in the
>>> QueryEntity. For example, if I create then alter a table via a SQL client
>>> with:
>>> ---
>>> CREATE TABLE test1 (
>>>   "key"      VARCHAR(30) NOT NULL,
>>>   "id"       BIGINT(20)  NOT NULL,
>>>   "testColumn1" VARCHAR(24) NOT NULL,
>>>   PRIMARY KEY("key"))
>>> WITH "affinitykey=key, backups=1, write_synchronization_mode=FULL_SYNC,
>>> atomicity=transactional, cache_name=test1, value_type=test1,
>>> key_type=arrivals_key";
>>>
>>> ALTER TABLE test1 ADD COLUMN  "testColumn2" VARCHAR(24) NOT NULL;
>>> ---
>>> ... then try to print out the result of
>>> "((QueryEntity)ignite.cache("test1").getConfiguration(
>>> CacheConfiguration.class).getQueryEntities().iterator().
>>> next()).getFields()"
>>> I get "{key=java.lang.String, id=java.lang.Long,
>>> testColumn1=java.lang.String}" which doesn't include the new column.
>>> Dropping columns is likewise not reflected.
>>>
>>> When I do try to query the cache via SQL, the added and dropped columns
>>> are
>>> reflected in the result, so it's clear the change didn't fail to go
>>> through
>>> entirely.
>>>
>>> Is there something I'm missing? Is it possible to alter a table and then
>>> detect the column changes in Java without entirely recreating the cache?
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>
>>

Reply via email to