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?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Any comment on this, how to fix it or prevent it from happening?
Views
Replies
Total Likes
Any particular reason to look at the mongo data directly? Can I know how is this causing an issue?
Views
Replies
Total Likes
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:
[1] https://docs.adobe.com/docs/en/aem/6-2/develop/communities/essentials/search.html#Default Search Properties
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies