<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Hi Robert,</div><div class=""><br class=""></div><div class="">to update a Person topic:</div><div class=""><br class=""></div><div class="">curl -H Cookie:JSESSIONID=nv23xiaj5n751et10ga74d1u -H Cookie:dm4_workspace_id=2954 -H Content-Type:application/json -X PUT localhost:8080/core/topic/4703 -d '{<br class="">    "childs": {<br class="">        "dm4.contacts.person_name": {<br class="">            "dm4.contacts.last_name": "Schmidt-Schacht"<br class="">        },<br class="">        "dm4.contacts.phone_number#dm4.contacts.phone_entry": [<br class="">            {<br class="">                "value": "0177 123 45 000",<br class="">                "assoc": {<br class="">                    "childs": {<br class="">                        "dm4.contacts.phone_label": "ref_id:1912"<br class="">                    }<br class="">                }<br class="">            }<br class="">        ]<br class="">    }<br class="">}'<br class=""><br class=""></div><div class=""><br class=""></div><div class="">To update a topic PUT the new topic data to the "/core/topic/<id>" resource. Here <id> stands for the ID of the topic to update. Pass the new topic data in the request body as a JSON object.</div><div class=""><br class=""></div><div class="">It is sufficient to pass only the topic data you want to change. The example changes the person's last name and adds a mobile number. Note that the person's first name is not contained in the update request and thus it will not change. You could say that the topic data in the update request is kind of "merged" with the current person data as stored in the DB.</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="EF7CA466-EF7A-4D51-A4FB-AFF94BC324D1" height="251" width="724" apple-width="yes" apple-height="yes" src="cid:C3423326-B0AF-42BF-A70C-0192F5A4ED04@localdomain" class=""></div><div class=""><br class=""></div><div class="">Lets investigate the Person model: you see that "Person" has "Phone" as a child type. Phone is a "simple" (in contrast to "composite") type and uses "Text" as its data type. Phone is defined with cardinality "Many", that is a Person can have many phone numbers. Furthermore Phone makes use of a Custom Association Type, which is "Phone Entry". That is at instance-level a Person topic will connect Phone topics via associations of type "Phone Entry". The association type "Phone Entry" is a composite type, which have "Phone Label" as a child type. 5 Phone Label instances are pre-defined by the dm4-contacts module: "home", "home fax", "mobile", "work", and "work fax".</div><div class=""><br class=""></div><div class="">To investigate the Person definition click the "Person" topic type, and then "Edit".</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="CE3FC8FE-BA8B-4FB5-9768-B0BD6F21A6BC" height="551" width="724" apple-width="yes" apple-height="yes" src="cid:64D4AD15-1193-46BD-8C37-A37717F186CF@localdomain" class=""></div><div class=""><br class=""></div><div class="">As topic type Phone (whose URI is "dm4.contacts.phone_number") is defined as "Many" you must specify an *array* in your update request:</div><div class=""><br class=""></div><div class="">    "dm4.contacts.phone_number#dm4.contacts.phone_entry": [</div><div class="">        ...<br class="">    ]<br class=""></div><div class=""><br class=""></div><div class="">(Remember from my previous posting, the "#dm4.contacts.phone_entry" qualification is required as the Phone definition makes use of a Custom Association Type.)</div><div class=""><br class=""></div><div class="">As "Phone" is a simple type you could just specify simple values in the array:</div><div class=""><br class=""></div><div class="">    [</div><div class="">        "123 456", "234 567", "345 678"</div><div class="">    ]</div><div class=""><br class=""></div><div class="">This would add 3 phone numbers to the person. However these would not be annotated by a Phone Label ("home", "mobile", ...). As a phone label is represented as a child topic of the association (that connects a Phone to a Person), the array elements in your update request must look like this:</div><div class=""><br class=""></div><div class="">    [<br class="">        {<br class="">            "value": "0177 123 45 000",<br class="">            "assoc": {<br class="">                "childs": {<br class="">                    "dm4.contacts.phone_label": "ref_id:1912"<br class="">                }<br class="">            }<br class="">        },<br class="">        {<br class="">            "value": "030 876 54 321",<br class="">            "assoc": {<br class="">                "childs": {<br class="">                    "dm4.contacts.phone_label": "ref_id:1909"<br class="">                }<br class="">            }<br class="">        }<br class="">    ]</div><div class=""><br class=""></div><div class="">This example adds 2 phone numbers to the person, one mobile number, and one home number. Here 1912 and 1909 are the IDs of the "mobile" and "home" Phone Label topics respectively.</div><div class=""><br class=""></div><div class="">Remember from my previous posting, the "ref_id:" prefix is needed as Phone Label is defined via Aggregation Definition (in contrast to Composition Definition). That is the pre-defined 5 Phone Label topics are supposed to be shared by all Phone Entry associations.</div><div class=""><br class=""></div><div class="">OK, now we've added 2 phone numbers to the person. If you want add another one, just PUT another array with one more element. But how can you specify that you want to *change* a particular element, to *delete* a particular entry?</div><div class=""><br class=""></div><div class="">If you want e.g. change the mobile number "0177 123 45 000" to "0177 123 45 111" you would PUT this array:</div><div class=""><br class=""></div><div class="">    [<br class="">        {</div><div class="">            "id": 4877,<br class="">            "value": "0177 123 45 111"<br class="">        }<br class="">    ]<br class=""><br class=""></div><div class="">Here, 4877 is the ID of the Phone topic you want to update. And: as the "assoc" property is not specified the Phone Label attached to the existing Phone Entry association will not change.</div><div class=""><br class=""></div><div class="">In order to update a particular child topic which is defined as "Cardinality Many" you must specify its ID. Otherwise DM can't know to which child topic your update data applies to. If no ID is given a new child topic with that data will be created.</div><div class=""><br class=""></div><div class="">Note that this is different for "Cardinality One" child topics. In this case no ID is needed (but will be no problem if contained in the request anyways). The update data applies to the one and only topic which exists already (resp. a new one is created if no one exists already).</div><div class=""><br class=""></div><div class="">OK, now about deleting a particular phone number:</div><div class=""><br class=""></div><div class="">    [</div><div class="">        "del_id:4877"</div><div class="">    ]</div><div class=""><br class=""></div><div class="">Besides "ref_id:" another way to refer to an existing topic is the "del_id:" prefix. The actual semantics of "del_id:" depends on wether the child is defined via "Composition Definition" or "Aggregation Definition". In case of Composition Definition the child topic itself is deleted. In case of Aggregation Definition however only the so-called "assignment" is deleted (that is the association that connects the child topic to the parent topic). The child topic itself is NOT deleted as it might still be shared with other parent topics.</div><div class=""><br class=""></div><div class="">In the example, 4877 is the ID of the Phone topic you want to delete. Note that Phone is defined via Composition Definition (as a Phone number is not shared by several Persons).</div><div class=""><br class=""></div><div class="">OK, how can your frontend know all the IDs of the person's child topics in order to build the one big Person update request?</div><div class=""><br class=""></div><div class="">In general you can ask the Core Service for a particular (single or composite) topic by using one of these 3 GET requests (assume 4703 to be the ID of a Person topic):</div><div class=""><br class=""></div><div class="">    GET /core/topic/4703</div><div class="">    GET /core/topic/4703?include_childs=true</div><div class="">    GET /core/topic/4703?include_childs=true&include_assoc_childs=true</div><div class=""><br class=""></div><div class="">The 1st form just returns that Person topic, without its child topics.</div><div class="">The 2nd form returns the Person topic and *all* its child topics as well. You'll also get details about the associations that connect the childs to their parent topics (in the "assoc" property). However, in case these associations are *composite* as well (in contrast to *simple*) you'll NOT get the child topics of these associations.</div><div class="">These are included in the response if you use the 3rd form of the GET request.</div><div class=""><br class=""></div><div class="">So, to display an update form your frontend will typically send these requests:</div><div class="">- a GET request (2nd form) for the topic being edited</div><div class="">- further GET requests to build the combo boxes (as mentioned in my previous posting), this is one get-all-instances request (GET /core/topic/by_type/<uri>) for every child type which is defined as Aggregation Definition.</div><div class=""><br class=""></div><div class="">This way you'll have all the IDs available at client-side to update a composite topic of arbitrary complexity, including</div><div class="">- creating new child topics</div><div class="">- updating child topics</div>- deleting child topics<br class=""><div class="">- assign existing child topics</div><div class="">- re-assign child topics</div><div class="">- deleting child topic assignments </div><div class="">- all supported for both, single-valued and multiple-valued childs ("Cardinality")</div><div class=""><br class=""></div><div class="">And all that in a single request, that is in a single database transaction.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Jörg</div><div class=""><br class=""></div></body></html>