Re: Feature request: Ignite SQL Rename table support

i just opened https://issues.apache.org/jira/browse/IGNITE-7051 -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC thin client load balancing and failover support

This ticket is slotted for 2.4 and seems to be related. https://issues.apache.org/jira/browse/IGNITE-6942 @Val, can you please link it with IGNITE-7029? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Feature request: Ignite SQL Rename table support

Use case is discussed at length: http://apache-ignite-users.70518.x6.nabble.com/Continuous-update-Data-Grid-Cache-td2075.html#a17641 Currently, we have to load data to second table, the client then has to change their query to query this new table. Drop the old table. The latest suggestion in t

JDBC thin client load balancing and failover

It appears Ignite has load balancing support for its compute grid but not for data grid. As in, the JDBC thin client does not have load balancing and failover support. If JIRA for it does not exist yet, can we create a JIRA for Ignite JDBC thin client to provide load balancing and failover suppor

Unable to query Ignite 2.3 table using 2.2 JDBC thin client

Hey, I run *Ignite 2.3* locally for testing...just one node, persistence is enabled. Using DBeaver - using *Ignite 2.2 *JDBC thin client, 1. Create two simple tables, City and Person, from the Getting started example. 2. Insert rows to those tables When I execute 'select * from Person', I got "

Re: Query performance against table with/out backup

@Andrew Mashenkov, I notice that you opened IGNITE-6781. However, I actually destroyed the original cache with backup == 1, recreate a new cache with backup ==2 and repopulate the table. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Continuous update Data Grid Cache

The use case is similar to OP. We have a large table that we import/load from a dataset. This dataset is generated periodically such that we need to re-load this whole dataset to Ignite. If we re-load the new dataset against the same Ignite table, the users will be impacted during that window.

Re: Node and cluster maintenance best practice

Thank you, Denis. How about best practice for bringing down a node for maintenance (e.g. applying OS patch, hardware maintenance, etc)? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Continuous update Data Grid Cache

Resurrecting this old thread. What is the current recommendation for the OP use case? Does Ignite support/plan to support aliases for cache name? I think this is really great feature to have to minimize client interruption/pain to switch to different cache. -- Sent from: http://apache-ignite-

Re: Query performance against table with/out backup

Here, I am trying to ascertain that I set backup == 2 properly as I mentioned above that I do not see query performance difference between backup ==1 and backup == 2. I want to make sure that I configure my cache properly. When I set the backup==2 (to have three copies), I notice the following v

Node and cluster maintenance best practice

Hello, I searched this topic, I can't seem to find it anywhere. Apology in advance if this is covered somewhere.. In multi nodes cluster and persistence is enabled, what is the best practice to bring down a node for maintenance (e.g applying OS patches, hardware upgrade, etc)? If one just stops

Re: Query performance against table with/out backup

Can you elaborate more on why if there is a scan, Ignite will have to scan the backup as well? Also, it appears adding additional number of backup (backup ==2 instead of 1) does not incur additional performance cost? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Query performance against table with/out backup

The table is created programmatically, two properties (zone and userId) were marked(annotated) with index = true. When you say, if the index are applied properly to the query, do you mean whether I provide the index hint to the query or else? If the former, the answer is no. The performance issu

Query performance against table with/out backup

Hello, We have a table with the following configuration: 1. Persistence is enabled 2. Partition (not replicated) 3. Backup = 1 vs. 0 Everything else, pretty much use default. We have a table in which we perform the following query: SELECT COUNT(*) FROM Table WHERE column1 > 0.75 AND column2 > 0.7

Re: Data (that is inserted via JDBC) is not persisted after cluster restart

I deleted everything under the work dir on all nodes, now, I am not able to reproduce it for new tables that I created. I am still seeing the issue on one of the tables that I created in the past. We experimented with so many different things, perhaps, something was cached/stored elsewhere besid

Re: Data (that is inserted via JDBC) is not persisted after cluster restart

The config file: IgniteConfig.xml No source code is provided as the issue is reproduce-able from SQL tool such as DBeaver. As far as logs, I have not configured ignite.-log4j.xml (as in it is still default). Do you wa

Re: Data (that is inserted via JDBC) is not persisted after cluster restart

I think it is unlikely I have problem described in IGNITE-6285. It is consistent that the data on the table that is inserted via IgniteDataStreamer (table created via Ignite getOrCreateCache) persist after cluster restart. I am using JDBC thin client, I both use it programmatically. I also confi

Data (that is inserted via JDBC) is not persisted after cluster restart

Hi, I configure my Ignite 2.2 nodes to enable persistence to disk. After cluster restart, I notice that data that is inserted via JDBC is gone. Note: if I programmatically create the cache/table and insert entries to the cache, these data pers