borinquenkid commented on issue #12142: URL: https://github.com/apache/grails-core/issues/12142#issuecomment-5099028483
Closing as won't-fix. Verified this is still unimplemented as of the 8.0.x branch. However, the requested behavior is not compatible with GORM's data binding and, realistically, never will be. `propertyName[index].field` notation (e.g. `people[0].id`) is already the syntax GORM's data binder uses to bind indexed `List`/`Set`/array associations — it reads these flat parameter keys itself during binding. Having `GrailsParameterMap` eagerly parse `foo[0].bar` into a grouped submap under `foo` (as requested here) corrupts the value the binder receives for indexed collection properties, breaking that binding path. I implemented the change described in #12148 against 8.0.x and confirmed it regresses existing indexed-collection binding: `DataBindingTests#testBindingWithIndexedBlankId`, `#testUpdatingSetElementByIdThatDoesNotExist`, `#testBindingObjectsWithHashcodeAndEqualsToASet`, and `#testBindintToNestedArray` all fail with the change applied, and all pass without it. There's no way to distinguish the two intents syntactically — `foo[0].bar` means "group by index" under this proposal and "bind element 0 of collection foo" under existing GORM behavior, and they're the same string. A fix would require rethinking indexed collection binding at the data-binder level rather than in `GrailsParameterMap`. See #12148 for the PR closure with the same finding. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
