Timeline for associated_users does not have a root level key
Current License: CC BY-SA 2.5
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2010 at 14:59 | comment | added | Kevin Montrose |
@code poet - You're keying data, it isn't a horrible kludge to have to construct the keys yourself. Asking for 100% duplicated data in a return to simply your - and, probably, only your - code is a bit much. Just reach into the on_site object if you have to. I still think defining an equality operator is the most elegant solution.
|
|
| Jun 18, 2010 at 14:50 | comment | added | Sky Sanders | I don't want to have to construct artificial structures and hook the deserialization process with extra measures. I want the data being returned from the api be shaped in a way that is usable as-is. And if that can be done with the inclusion of a field here or there, why not do it? It is not like I am suggesting some outrageous smelly kludge, I am begging for a simple small degree of normalization. | |
| Jun 18, 2010 at 14:46 | comment | added | Sky Sanders | as i said, i can see how the nested site structure could be an illustration of acceptable denormalization. But what you seem reluctant to acknowledge in this and other cases is that your denormalization does not simplify the task of consuming the data. You keep suggesting that we should make efforts to manipulate the data and the structures we create to arrive at what would be seen as a usable result when the inclusion of one simple field of data, that you already have in hand, in the root of the structure in question would allow direct deserialization into a usable object. | |
| Jun 18, 2010 at 14:25 | history | answered | Kevin Montrose | CC BY-SA 2.5 |