Denis, hello. Thanks for your explanation. I can see some difficulties in
matching your new idea with the current functionality of key-value approach.
>From this point of view, Alexey Kukushkin's approach looks less confusing to
me and easier to implement. But this could be due to the lack of
Hi Alexey,
Let me answer the second question first
How would you change ICache interface which has this member?
We will keep the key-value interface at least for backward compatibility.
Plus, it might be preferred by those who use caching APIs only. So, this
method will stay as-is.
What
> Nikolay, btw, what's your thinking on the approach proposed by me?
Makes sense.
> 26 мая 2020 г., в 14:07, Alexey Sasov написал(а):
>
> Hello. Looks good. What whould be returned from the query like this "select
> _key from cache" if we don't know the type of the key? ExpandoObject, Tuple,
>
Hello. Looks good. What whould be returned from the query like this "select
_key from cache" if we don't know the type of the key? ExpandoObject, Tuple,
BinaryObject? How would you change ICache interface which has this member?
/// Queries cache.
/// Query.
/// Cursor.
Denis, I like your proposal and will be glad to participate in developing a
solution in that way.
In additional to Nikolay's opinion about your ideas I think it is important
to get Dmitry Frolov's (who started the discussion) and Alexey Sasov's (who
also voted for the having this enhancement)
Alexey,
If you support my idea, why don't we go ahead and support it for upcoming
Ignite releases? We'll preserve existing key-value APIs for now and will
rather expand them with a new set of methods that no longer require to pass
a key object. We'll be glad to work together with you on an IEP.
Nikolay,
I think you and I agree here: there is no problem at all if the user uses
K/Vs in domain model OR developed a domain-to-K/V mapper OR does not use SQL
DML.
I think we just have different experience as to how "popular" is the user's
unwillingness to use one of the three existing
Hello, Alexey.
Thanks for your feedback and clarification.
> you have to explicitly specify fields having the same name inside the Key and
> Value.
By all of this we just make Ignite more complex in favor of single, wrong
use-case.
Moreover, you hurt another use-cases with this feature.
I
> «Why SQL sets both fields? I just want to set the key object field!»
The solution from IGNITE-12807 has backward compatible API: you have to
explicitly specify fields having same name inside the Key and Value.
Otherwise the semantics is as is.
Denis's solution (that I like) is a new API not
> Personally, I treat this as an anti-pattern that should have been influenced
> by some of the old Ignite examples.
+1
I don’t see any reason to support fields with the same name both in key and in
value from SQL.
Moreover, I think if we implement this feature then for some part of the users
Denis,I like your idea. It would be like native "OKVM" (Object-KeyValue
Mapper) allowing Ignite to natively operate on domain entities. It also
means no key and value data duplication and thus addressing the original SQL
DML problem when only key field is modified.We could add a
>
> I do acknowledge that this awkward usability issue is quite annoying and
> complicates applications' architecture. Problem with Spring Data
Sorry, sent the message with the first paragraph left unfinished. "Problem
with Spring Data" - just wanted to highlight that the current separation on
Folks, thanks for the details. I do acknowledge that this awkward usability
issue is quite annoying and complicates applications' architecture. Problem
with Spring Data
At the moment, I use the workaround mentioned by Alexey Kukushkin. Guess
many of us already use it in productions:
-
I vote for implementing this enhancement: having key information separated
from value means either cluttering domain model with
KeyValue/CacheEntry-like structures or developing an Ignite data access
layer to insert key info into domain entity after getting it from Ignite.
Although both the
Hello, Denis. This is the analogy of DB records. We've got keys in the table.
But querying the record with the key we also have this key in the returned
record. The question of having all data in the value is a domain driven one.
If i have a model (ex. Person) containing PassportNo, I don't want
Hi Dmitry,
PersonKey { id: int, passportNo: String }
> Person { passportNo: String, name: String }
What's the primary reason for keeping a copy of "passportNo" field in the
value object? Personally, I treat this as an anti-pattern that should have
been influenced by some of the old Ignite
Hello. Sure this feature is of great importance and we'd like to get it asap.
It is very confusing to support the logic of copying values between key and
value classes.
Thanks.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
17 matches
Mail list logo
