[deepamehta-devel] REST API JSON export and re-import

[Jörg Richter]

Hi Jürgen,

let me elaborate more on your question here.

The example commands assume the source instance runs at 8080, and the target instance runs on 8088


> On 25 Nov 2017, at 23:43, Jörg Richter <jri at deepamehta.de> wrote:
> 
> Hi Jürgen,
> 
> in your particular case you can achieve the export/import with these 4 requests:
> 
> At source instance:
> 1) GET the ID of the sign-up config topic by querying it by-uri. Its URI is well-known.

curl localhost:8080/core/topic/by_uri/org.deepamehta.signup.default_configuration?include_childs=true

The response is the complete config topic, including its child topics.

> 2) GET the config data by querying the sign-up config topic by-ID, including its child topics.

This is not necessary. You can do this in a single request (see step 1)

> At target instance:
> 3) GET the ID of the sign-up config topic by querying it by-uri. Its URI is well-known.

curl localhost:8088/core/topic/by_uri/org.deepamehta.signup.default_configuration

The response is the config topic.
It's ID is accessible as the (top-level) "id" property.

> 4) PUT the received data (step 2) as-is to the config topic by-ID (as received in step 3).

curl -X PUT localhost:8088/core/topic/<config-topic-id> -d <topic-data>

<config-topic-id> is the ID obtained in step 3)

<topic-data> is the response data obtained in step 1)

IMPORTANT:
In the <topic-data> you must replace the (top-level) "id" property with -1 (as JSON number, no " ") or, alternatively, remove the "id" property completely. (It's best to use a tool for JSON manipulation here.)
Otherwise the PUT request will throw a "ID mismatch in update request" exception.
(The child topic IDs contained in <topic-data> must not necessarily be replaced/removed as these are effectively ignored in your case.)

Probably you must add a Content-Type header to the PUT request as well:

	-H Content-Type:application/json

All your requests need authorization.

CONCLUSION:

You transfer topic data basically by GETting them and then PUTting them to another (existing) topic. But note that this works only if several prerequisites are met:

- the target topic exists already on the target instance. (Otherwise you need to create it, by using POST, instead of PUT.)
- the type definition exists already. (Otherwise you must create it first.)
- the type definition involves only "Composition Defs". (For Aggregation Defs you need special syntax in case you want refer to shared child topics.)
- the type definition involves only cardinality "One". (For updating cardinality "Many" child topics you need their particular IDs.)
- no associations needs to be transferred. (You would need to map between source instance topic IDs and target instance topic IDs.)

For your particular case (transferring the sign-up config) the solution described here will work, but it is far away from a generic export/import scenario (as your mail subject suggests).

With DM5's new Identity/Value data model (upcoming) transferring data between instances will become more straight-forward.

Cheers,
Jörg

-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr��e  : 488 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.deepamehta.de/pipermail/devel-lists.deepamehta.de/attachments/20171126/69f3683e/attachment.sig>