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 don’t think it’s a right for the Ignite. Let’s hear another opinion. > - Many are the existing (legacy) apps adding Ignite as one of the pieces. But in your example POJOs that are developed especially for Ignite. > I already mentioned popular problems should be solved in re-usable parts I don’t think it's a popular issue. From my understanding it’s a union of the following design choices: 1. Don’t want to pass both KEY and VALUE objects to the application logic layer - therefore we want to duplicate some fields both in KEY and in VALUE. 2. Want to use SQL Updates to manage KV objects. Both of these decisions is questionable: 1. Can we work with two objects on the business logic layer? 2. Can we combine KEY and VALUE in the single object before passing it on the application logic layer? 3. Updating entities from SQL has significant downsides - no transactions support, no atomic changes, etc. > 22 мая 2020 г., в 10:06, Alexey Kukushkin <kukushkinale...@gmail.com> > написал(а): > >> «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/
