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 configuration-based alternative to the AOP-style API you suggested. Of all languages that Ignite supports I think only Java and C# have AOP. We need to think about all languages when we add a new feature. I think your solution does not completely overlap with the solution suggested in IGNITE-12807 <https://issues.apache.org/jira/browse/IGNITE-12807> : - You suggested a new API that does not have a "Key" entity by definition. A huge advantage of the existing Key/Value is it is a widely adopted JCache standard supported by all Ignite competitors I am aware of. That means low cost of switching to Ignite for users of other product and more confidence for existing Ignite users. IGNITE-12807 suggests solving the problem with the Key/Value API. - Implementing your solution is probably a significantly bigger effort than what IGNITE-12807 suggests. IGNITE-12807 already has a patch with a proof-of-concept implemented.Still, I think the urge for addressing it in K/V API would be less if we have your kind of API in Java and C#.
-- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/