MSRP Bug? - First time updating existing UGC documents duplicates "id" field

[Gdubz-57m2mu]

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[1], 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:

{ "_id" : "e105d612d5e2d0cb920b86d7a4cd0bea46cddc23", "resource_type_s" : "myproject/components/homepage/social_test", "parent_id_s" : "/content/myproject/en/home/jcr:content/socialTest", "provider_id" : "/content/usergenerated/asi/mongo/content/myproject/en/home/jcr:content/socialTest/userOne", "report_suite" : "mongo", "id" : "/content/usergenerated/asi/mongo/content/myproject/en/home/jcr:content/socialTest/userOne", "author_username" : "userOne", "cqdata" : { "jcr:date" : "2016-11-18T11:00:15.114-0600", "jcr:primaryType" : "nt:unstructured", "customProp" : “customValue” }, "timestamp" : NumberLong("1479488415269") } { "_id" : "24bcaff69a130ab938e21a5bb20247a7b04aad68", "resource_type_s" : "myproject/components/homepage/social_test", "parent_id_s" : "/content/myproject/en/home/jcr:content/socialTest", "provider_id" : "/content/usergenerated/asi/mongo/content/myproject/en/home/jcr:content/socialTest/userTwo", "report_suite" : "mongo", "id" : "/content/usergenerated/asi/mongo/content/myproject/en/home/jcr:content/socialTest/userTwo", "author_username" : "userTwo", "cqdata" : { "jcr:date" : "2016-11-21T11:00:48.214-0600", "jcr:primaryType" : "nt:unstructured", "id" : "/content/usergenerated/asi/mongo/content/myproject/en/home/jcr:content/socialTest/userTwo", "customProp" : "customValue" }, "timestamp" : NumberLong("1479740515389") }

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?

[1] https://github.com/Adobe-Marketing-Cloud/aem-communities-todomvc-sample/blob/master/bundles/aem-comm...

[Gdubz-57m2mu]

It would appear that even removing the "id" from the ModifiableValueMap just results in setting "id":null on the Mongo document after committing changes. So forget that idea, as it won't work.

[Gdubz-57m2mu]

Any comment on this, how to fix it or prevent it from happening?

[pparkar]

Any particular reason to look at the mongo data directly? Can I know how is this causing an issue?

[Gdubz-57m2mu]

pparkar wrote...

Any particular reason to look at the mongo data directly? Can I know how is this causing an issue?

Because the SRP API is new to me, attempting to implement it into our project's codebase, and I'm a curious individual.

It is not actually causing a problem right now. I'm simply wondering why it happens? Something to do with the SRP API's translation of property keys between Java and MongoDB, I'm guessing. Which is something that I find extremely weird...

Is there any documentation for mapped Java keys to MongoDB keys? The best I could find is this table of Default Search Properties[1], but that's only half of what I'm looking for. For example:

• JcrResourceConstants.SLING_RESOURCE_TYPE_PROPERTY ("sling:resourceType") gets converted and stored as "resource_type_s" in MongoDB.
• PropConstants.AUTHORIZABLE_ID ("authorizableId") gets converted and stored as "authorizableId_t" in MongoDB (curious, what benefits/differences of Text over String?)
• ...etc

[1] https://docs.adobe.com/docs/en/aem/6-2/develop/communities/essentials/search.html#Default Search Properties

[pparkar]

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.

[Gdubz-57m2mu]

pparkar wrote...

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[1].

I'm doing exactly that and it is causing this duplicate "id" field.