Re: Error in JDBC store

[Dmitry Karachentsev]

Opened a ticket for that [1].

[1] https://issues.apache.org/jira/browse/IGNITE-4515

On 29.12.2016 23:07, Valentin Kulichenko wrote:

Hi Dmitry,

My opinion is that this is not a valid case and we should throw an
exception on cache startup if two Java fields are mapped to the same DB
field. Even if user needs such duplication on objects level (which I also
doubt, BTW), the mapping in the store must be correct.

-Val

On Thu, Dec 29, 2016 at 12:23 AM, Dmitriy Karachentsev <
dkarachent...@gridgain.com> wrote:


Hi all!

According to this thread [1] in JDBC store configuration:
1. Map key and value fields to the same columns in DB.
2. Try to update data.
3. Got invalid SQL.

Let's see an pseudocode example of described use case.
KeyClass { field1; field2; field3 }, ValClass { field1; field2; field3 }

Map fields to DB table TABLE_NAME columns: field1 -> col1, field2 -> col2,
field3 -> col3.

User expects the following update request built by Ignite:
UPDATE TABLE_NAME SET col1=?, col2=?, col3=? WHERE (col1=?, col2=?,
col3=?);

But Ignite checks that value object fields have the same mappings, throws
them away and builds wrong query:
UPDATE TABLE_NAME SET WHERE (col1=?, col2=?, col3=?);
That is obviously wrong.

Is there any reason to do so?
Probably, it is better to build query according to user mapping and
delegate verification to DB.

[1]
http://apache-ignite-users.70518.x6.nabble.com/Error-
while-writethrough-operation-in-Ignite-td9696.html

Thanks!
Dmitry.

[jira] [Created] (IGNITE-4515) Throw exception when key and value fields mapped to the same DB columns

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4515:
---

 Summary: Throw exception when key and value fields mapped to the 
same DB columns
 Key: IGNITE-4515
 URL: https://issues.apache.org/jira/browse/IGNITE-4515
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.8
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
 Fix For: 2,0


In case of (pseudocode):
KeyClass { field1; field2; field3 }, ValClass { field1; field2; field3 }

Map fields to DB table TABLE_NAME columns: field1 -> col1, field2 -> col2, 
field3 -> col3.

On node startup throw an exception with message that restricts such case. Field 
mappings should not intersect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: PageMemory approach for Ignite 2.0

[Vladimir Ozerov]

Dima,

Performance is a serious concern, but not the main one. My point is that
standard users working on commodity hardware and requiring only in-memory
mode simply do not need page memory. They need distributed HashMap. We
already have it. It is fast, it is stable, it have been tested rigorously
for years. It does what users need.

PageMemory approach targets high-end deployments which is hardly represents
majority of our users. Less than 10% I think. Or may be <5%, or even <1%.
This is who may benefit from page memory. Others will benefit nothing
except of additional layer of indirection, drop in performance, risks of
instability. And problems with capacity planning, because it is much harder
to plan two memory regions properly than a single one.

I talked to Alexey Goncharuk some time ago, and he told it is not a big
deal to abstract out PageMemory. Alex, please confirm. I encourage everyone
to stop thinking of dropping "old" before you have built "new" and
confirmed that it is better.

Let's ensure that new approach is well-abstracted, add it to 2.0, let it
maturate for 1-2 years, and then think of dropping current approach in 3.0.
This sounds much better to me.


On Sun, Jan 1, 2017 at 10:42 AM, Denis Magda  wrote:

> Sorry, just recalled that Unsafe is not JNI based. However, my previous
> point of view still remains the same.
>
> > On Dec 31, 2016, at 11:39 PM, Denis Magda  wrote:
> >
> > JNI-based Unsafe that also brings performance hit
>
> —
> Denis
>
>