new links are "merged" into existing documents

[abalmos]

For example, if at

/bookmarks/services/trellis/signer there is an object

{
   "jobs": {}
}

and then one PUTs

{
  "_id": "resources/123"
}

to /bookmarks/services/trellis/signer.

In this case, /bookmarks/services/trellis/signer/blah correctly follows the new link. However getting /bookmarks/services/trellis gives back something like:

{
  "jobs": {},
  "_id": "resources/123"
}

and jobs is not ever accessible.

It appears PUTs of links are "merged" into existing paths but that doesn't make a lot of sense.

[awlayton]

I suppose OADA treats links as a primitive of sorts, so in that case one might expect the link to replace whatever was there?

[aultac]

That must explain how Tomo’s library was able to get those _type’s in there inadvertently. I believe at the moment, if you put an object that has _id in it, it ignores all other keys at that level in the put body (except the optional _rev). So you can’t get extra stuff into a link object in one go, you’d have to put an object there first, then put a link there second. I agree with you guys the correct behavior should be that putting an object with `_id` in it should completely wipe out whatever was there before, just like putting a string to a key would completely wipe out a pre-existing object at that key. That is probably tricky to accomplish in a single go w/ Arango. Aaron

…

On Mar 13, 2021, at 12:01 AM, Alex Layton ***@***.***> wrote: I suppose OADA treats links as a primitive of sorts, so in that case one might expect the link to replace whatever was there? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2KEUAV3AEDN3HMX33S4TDTDLPPZANCNFSM4KKMXUKA>.

[awlayton]

It would make the query more complicated yes. We would need to do something with MERGE_RECURSIVE rather than simply doing an UPSERT with the changes as we do now.