> «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 changing the K/V API at all. > We want to make Ignite(or any database) too smart. I agree that introducing a new feature or even a new small configuration setting often makes a product more complex: more expensive to learn and maintain. One should think hard whether benefits of some new function overweight added complexity to the product. To me in this case complexity and costs of the new configuration setting (KeyValue field list in QueryEntity and CREATE TABLE params) justifies the value for the users. In my experience "just rename the fields" is a huge inconvenience for real applications: - Many are the existing (legacy) apps adding Ignite as one of the pieces. Many are large enterprise apps with many thousands lines of code deployed in mission critical PROD environments. Such apps already have a domain model used by other enterprise components. "Renaming a field" in the domain model entities is just not a practical solution for them. They will choose developing a data access layer to map domain model to K/Vs. - As for having the user to always develop a data access layer - I already mentioned popular problems should be solved in re-usable parts, which is Ignite in this case. Besides, additional layers have performance and memory impact and the suggested solution has none. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
