LINKMAP + mandatory LINK field fails in recursive save within a transaction

[riverlover]

Description

In OrientDB 3.x(Mine is 3.2.43) , when recursively constructing an ODocument tree within a transaction, the following scenario can trigger a validation error:

• Child documents contain a mandatory LINK field (e.g., model)
• Child documents are not yet saved (temporary RIDs are assigned)
• The parent document stores child documents in a LINKMAP

Even if the model field is set in memory for each child, committing the transaction fails.

Error message:

The field 'DataValue.model' is mandatory, but not found on record: StringValue#69:-2
com.orientechnologies.orient.core.exception.OValidationException: 
The field 'DataValue.model' is mandatory, but not found on record: StringValue#69:-2

Steps to Reproduce (Scala example)

def objectValueToODocument(value: ObjectValue, modelDoc: OIdentifiable): ODocument = {
  val objectDoc = new ODocument("ObjectValue")
  objectDoc.field("model", modelDoc, OType.LINK)
  objectDoc.field("id", value.id)
  val children = value.children.map { case (k, v) => (k, dataValueToODocument(v, modelDoc)) }
  objectDoc.field("children", children.asJava, OType.LINKMAP)
  objectDoc
}

def dataValueToODocument(value: DataValue, modelDoc: OIdentifiable): ODocument = value match {
  case v: StringValue =>
    val doc = new ODocument("StringValue")
    doc.field("model", modelDoc, OType.LINK)
    doc.field("id", v.id)
    doc.field("value", v.value)
    doc
  case v: ObjectValue => objectValueToODocument(v, modelDoc)
  // Other types omitted for brevity
}

// Saving in a single transaction
db.begin()
val rootDoc = objectValueToODocument(rootObjectValue, modelDoc)
rootDoc.save()
db.commit()

Actual Result

Transaction commit fails with the error shown above, indicating that DataValue.model is missing on a temporary child document RID.

Expected Result

• OrientDB should correctly recognize mandatory LINK fields in temporary child documents within a transaction
• OR documentation should explicitly state that LINKMAP with mandatory LINK fields in a recursive save is not supported in a single transaction

Notes

• Temporary RIDs (#69:-2) are generated by OrientDB for unsaved child documents
• Saving child documents individually before saving the parent avoids the error, but breaks transactional rollback atomicity

[tglman]

Hi,

Yes this case should be supported, if you create a tree of documents (either embedded or linked) in memory, and than call save on one of them, it should save and link every document correctly, and temporary ids like #69:-2 are assigned on save during transaction, even if you do not save the specific document directly, it get saved when a linked document is saved, when not saved a document has id #-1:-1

The snippet you posted it looks all correct, you do assign the model at any case, it may be there an issue around the assign of the link before save, so something you can double check if that modelDoc is actually been saved.

I do not have the other code so if the modelDoc is the result of doc.getIdentity() before the doc is saved it may be of value #-1:-1 and not link correctly, if you pass the whole doc like you do on the other cases, or before do doc.getIdentity() you do db.save(doc); it should be all fine.

In any case here is the code that check the validation of fields: https://github.com/orientechnologies/orientdb/blob/3.2.44/core/src/main/java/com/orientechnologies/orient/core/record/impl/ODocument.java#L675

specific check for mandatory is here: https://github.com/orientechnologies/orientdb/blob/3.2.44/core/src/main/java/com/orientechnologies/orient/core/record/impl/ODocument.java#L703

This may be useful to go in debug and see what is actually happening, I'm just speculating the logic from the code I saw.

[riverlover]

@tglman Thanks for the reply! I tried again and found something interesting:

objectDoc.field("model", modelDoc, OType.LINK)

If modelDoc is an already persisted document (not created in the current transaction), I consistently get the error:

The field 'DataValue.model' is mandatory, but not found on record: StringValue#69:-2

But if modelDoc is a new document created inside the same transaction (e.g. by temporarily inserting a model like this):

val model = new ODocument("Model")
model.field("modelId", modelId)
// model.field("collection", "#46:51")
model.field("modifiedTime", new Date())
model.field("version", 1)
db.save(model)

…then everything works fine, and no validation error occurs.

So the behavior seems different depending on whether the linked model is persisted beforehand or created in the same transaction.

---

I’ve tested further and confirmed that the issue only happens when there is a link to an already persisted record inside the document being inserted. For example:

model.field("collection", "#46:51")

As soon as such a persisted record is referenced, the commit throws the same validation error.

If all links (like model) are created fresh inside the same transaction, everything works normally. But the moment a previously persisted record is included, the error appears.

So it looks like the validation problem is specifically triggered when mixing new transactional documents with already persisted documents in the same recursive save.

---

[riverlover]

After some more testing I found another detail:

When the mandatory constraints are defined on classes like:

• StringValue
• DoubleValue
• ObjectValue
• ArrayValue
• BooleanValue

for fields such as id, value/children, and model, the transaction throws the mandatory field missing validation error.

But if I remove these mandatory constraints, then the errors no longer appear and the data is inserted successfully, with the structure looking correct.

So it seems the validation failure is tied to the mandatory constraint checks, even though the data itself is properly persisted.

---

So it seems the validation failure is tied to the mandatory constraint checks, even though the data itself is properly persisted. My suspicion is that this may be a conflict between the mandatory validation and how temporary RIDs are handled during transactional recursive saves.