Re: Default hash code generation strategy for new binary objects

Guys, We need to look at 3 cases: a) key is just one field b) key is multiple fields c) key is one or multiple fields, with possibility of an alternate affinity key For (a) and (b), whenever a type is defined in XML, and further in DML, a user will specify which fields are part of the key. In

Re: Default hash code generation strategy for new binary objects

Let me show the picture I have in my mind: Primary key is a must for all INSERT and MERGE operations. If it’s not set then an INSERT/MERGE fails. If a primary key is a boxed/unboxed primitive (int, Integer, String, Date, etc.) then the key value is used for hashCode calculation. At the same

Re: Default hash code generation strategy for new binary objects

Also MERGE. 2016-09-29 2:10 GMT+03:00 Denis Magda : > You need a hash code only for INSERT operation, right? > > — > Denis > >> On Sep 28, 2016, at 3:47 PM, Alexander Paschenko >> wrote: >> >> But what if the user works from some kind of

Re: Default hash code generation strategy for new binary objects

You need a hash code only for INSERT operation, right? — Denis > On Sep 28, 2016, at 3:47 PM, Alexander Paschenko > wrote: > > But what if the user works from some kind of console and just types > the queries as text in full and does not bind params via JDBC

[jira] [Created] (IGNITE-3999) Support case insensitive search in SQL

Valentin Kulichenko created IGNITE-3999: --- Summary: Support case insensitive search in SQL Key: IGNITE-3999 URL: https://issues.apache.org/jira/browse/IGNITE-3999 Project: Ignite Issue

Re: Default hash code generation strategy for new binary objects

But what if the user works from some kind of console and just types the queries as text in full and does not bind params via JDBC or something alike? What if there's no binary object? I don't see why we should keep the user from usual cache gets in this case. I really like the idea of supplying

Re: Default hash code generation strategy for new binary objects

Hmm, this is a good question. If a user doesn’t provide a _key when an INSERT is executed for me it means that he is not going to use the key later for cache.get/put, DELETE, UPDATE and other possible operation simply because he doesn’t know how to reconstruct the key back in his code. If he

Re: Default hash code generation strategy for new binary objects

Denis, That's not what I was asking about. Currently DML implementation allows for dymanic instantiation of keys, in other words, user does not have to provide value for object-typed _key column - instead, he may supply just field values based on which _key will be dynamically instantiated/binary

Re: Default hash code generation strategy for new binary objects

Alexander, As I guess if we have a key without a class then it will be constructed using a BinaryBuilder instance and it’s user responsibility to set the has code at the end with BinaryBuilder.hasCode method. Sure, all this cases must be well-documented in both Java Doc API and Apache Ignite

Re: Default hash code generation strategy for new binary objects

Dmitry, Denis, OK, but I think it's necessary to address also the cases when there's no actual class for the key, and its fields are simply declared in XML. In this case, there are no fields to be marked transient. What do we do then? List transient fields in XML separately? - Alex 2016-09-28

[GitHub] ignite pull request #1129: Ignite 3998

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/1129 Ignite 3998 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3998 Alternatively you can review and apply

[jira] [Created] (IGNITE-3998) IGFS: uncomment testCreateConsistencyMultithreaded

Ivan Veselovsky created IGNITE-3998: --- Summary: IGFS: uncomment testCreateConsistencyMultithreaded Key: IGNITE-3998 URL: https://issues.apache.org/jira/browse/IGNITE-3998 Project: Ignite

[jira] [Created] (IGNITE-3997) .NET: Readme.io documentation update for 1.8

Pavel Tupitsyn created IGNITE-3997: -- Summary: .NET: Readme.io documentation update for 1.8 Key: IGNITE-3997 URL: https://issues.apache.org/jira/browse/IGNITE-3997 Project: Ignite Issue

[GitHub] ignite pull request #928: IGNITE-3633 GridCacheUtils - validate hash code pr...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/928 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] ignite pull request #1128: IGNITE-3995 .NET: Fix default cache name in ASP.N...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1128 IGNITE-3995 .NET: Fix default cache name in ASP.NET Session-State Store Provider You can merge this pull request into a Git repository by running: $ git pull

[jira] [Created] (IGNITE-3996) .NET: ASP.NET Output Cache provider run cache with default "null" name

Vasilisa Sidorova created IGNITE-3996: -- Summary: .NET: ASP.NET Output Cache provider run cache with default "null" name Key: IGNITE-3996 URL: https://issues.apache.org/jira/browse/IGNITE-3996

[jira] [Created] (IGNITE-3995) .NET: ASP.NET Session-State Store Provider run cache with default "null" name

Vasilisa Sidorova created IGNITE-3995: -- Summary: .NET: ASP.NET Session-State Store Provider run cache with default "null" name Key: IGNITE-3995 URL: https://issues.apache.org/jira/browse/IGNITE-3995

[jira] [Created] (IGNITE-3994) Client buffer CacheContinuousQueryEntry on pendingEvts after reconnect to alive cluster.

Vladislav Pyatkov created IGNITE-3994: - Summary: Client buffer CacheContinuousQueryEntry on pendingEvts after reconnect to alive cluster. Key: IGNITE-3994 URL:

[jira] [Created] (IGNITE-3992) Process failing Hibernate tests.

Vladimir Ozerov created IGNITE-3992: --- Summary: Process failing Hibernate tests. Key: IGNITE-3992 URL: https://issues.apache.org/jira/browse/IGNITE-3992 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3993) Process failing client nodes tests.

Vladimir Ozerov created IGNITE-3993: --- Summary: Process failing client nodes tests. Key: IGNITE-3993 URL: https://issues.apache.org/jira/browse/IGNITE-3993 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-3991) Process failing IGFS tests.

Vladimir Ozerov created IGNITE-3991: --- Summary: Process failing IGFS tests. Key: IGNITE-3991 URL: https://issues.apache.org/jira/browse/IGNITE-3991 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3990) Process failing Spring tests.

Vladimir Ozerov created IGNITE-3990: --- Summary: Process failing Spring tests. Key: IGNITE-3990 URL: https://issues.apache.org/jira/browse/IGNITE-3990 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3989) Process failing JTA tests.

Vladimir Ozerov created IGNITE-3989: --- Summary: Process failing JTA tests. Key: IGNITE-3989 URL: https://issues.apache.org/jira/browse/IGNITE-3989 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3988) Process failing cloud tests.

Vladimir Ozerov created IGNITE-3988: --- Summary: Process failing cloud tests. Key: IGNITE-3988 URL: https://issues.apache.org/jira/browse/IGNITE-3988 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-3987) ODBC: Improve error output when query parsing failed.

Vladimir Ozerov created IGNITE-3987: --- Summary: ODBC: Improve error output when query parsing failed. Key: IGNITE-3987 URL: https://issues.apache.org/jira/browse/IGNITE-3987 Project: Ignite

[GitHub] ignite pull request #1127: ignite-1.7.2

GitHub user sboikov opened a pull request: https://github.com/apache/ignite/pull/1127 ignite-1.7.2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1.7.2 Alternatively you can review and apply these