He Eugene,
To elaborate on Ilya's answer, you can define a POJO for your key like as
follows:
public class AccountKey {
String email;
String phoneNumber;
//don't forget to implement equals() and hashCode() so
// that Ignite partitions and locates your records properly
}
and then use the objects of that type in your cache.get/put requests.
-
Denis
On Tue, Jun 30, 2020 at 1:04 PM Eugene McGowan <[email protected]>
wrote:
>
> On Tue 30 Jun 2020, 13:51 Ilya Kasnacheev, <[email protected]>
> wrote:
>
>> Hello!
>>
>> You can also use Binary Object (POJO) as a key, i.e., you can use an
>> Object with String email and String phone fields.
>>
>> I don't recommend mangling strings further than concatenation. String key
>> is no worse than numeric key.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 30 июн. 2020 г. в 15:17, Eugene McGowan <[email protected]>:
>>
>>>
>>> We would like to create an Ignite key by concatenating data. This is a
>>> standard distributed system pattern for key-value, and would allow the
>>> reader and writer consistently access the cache. The data is a combination
>>> of strings and integers. To simplify our use case, lets say its an email
>>> address ([email protected]) and phone number (123444) we want to use to build
>>> our key.Our key could therefore be:[email protected]_123444
>>> <[email protected]_123444>The advantage of this approach is the key can
>>> easily be read/debugged. Is there a more optimum format for Ignite though?
>>> For regular RDBMS, it seems integers were the default choice. We could
>>> convert [email protected] to an int, e.g. f converts to 6, o to 15, etc.
>>> This naïve first attempt of conversion would of-course lead to clashes,
>>> as 111 could map to either aaa or ak. This could be worked around
>>> potentially, so looking for an initial steer on what Ignite would prefer as
>>> a key (i.e. strings or ints). Is hashing something that would be
>>> recommended either? In terms of any partitioning type logic, we are
>>> guessing not, but just more around creating deterministic, unique keys
>>>
>>
