So I noticed something when running a test on my local. If I were to get a ModifiableValueMap in order to update an existing UGC resource, using the example provided on Github, then when saving, the SRP API is essentially duplicating the "id" field. This field is not something I'm providing on initial UGC creation, my guess is that the SRP API is creating it. It exists in the ModifiableValueMap when I go to update a given value, and when saving my changes, the SRP API is adding it back as "cqdata".
Look at the same MongoDB document data below for an example of what I'm talking about:
The first record above for "userOne" had only ever been created, never updated. The second record for "userTwo" had been updated recently and upon saving, the "id" field gets duplicated, the original "id" field on the first level of the document remains, and yet it's being added again under "cqdata" object level.
I could probably get around this by just removing the "id" field after I've fetched a ModifiableValueMap, but I thought I would bring it to your attention to confirm that it is indeed a bug or perhaps something that I'm doing wrong when updating MSRP documents?
We dont mandate a social schema for SRP database at this point. Also, accessing SRP data directly from Mongo is not supported by Adobe. Its not a bug to have redundant field [here: 'id'] across bson data. Hope this helps.
I was only viewing SRP Data in MongoDB directly to see what was persisted as a result of my Java code utilizing the SRP API. While it's not a problem to have redundant fields in bson data, in general, it IS a bug of the SRP API that it creates this redundant field upon modifying a record. If it doesn't happen with OOTB components editing MongoDB documents through the SRP API, then you must be doing something different than what's outlined in example code provided by Adobe on Github.
I'm doing exactly that and it is causing this duplicate "id" field.