In some scenarios a user may want to create an object that is guaranteed to have a unique id. While this is relatively straightforward to accomplish in application code, if the object is created in a scope that is connected to a mount, this is harder to do in a way that does not introduce race conditions.
To accommodate for these scenarios mounts will be extended with a virtual onId method, which is invoked when a user is requesting a unique id from that mount. A user can request a unique id by leaving the id parameter of corto_declareChild or corto_createChild to NULL:
corto_createChild(root_o, NULL, corto_int32_o); // requests default id from mount
If no mount is available to provide a unique id and a user does not provide an id, corto_declareChild (and thus corto_createChild) will fail.
Default matching applies to finding a mount that can provide the id. For example, when the mount has a type filter, it will only be invoked when the user is trying to create an object of a matching type.
This behavior will only be invoked when the mount is configured to be a SINK, since this is a feature that exclusively makes sense for objects that are created locally (a remote object already got its id from the remote data source).
In some scenarios a user may want to create an object that is guaranteed to have a unique id. While this is relatively straightforward to accomplish in application code, if the object is created in a scope that is connected to a mount, this is harder to do in a way that does not introduce race conditions.
To accommodate for these scenarios mounts will be extended with a virtual
onIdmethod, which is invoked when a user is requesting a unique id from that mount. A user can request a unique id by leaving theidparameter ofcorto_declareChildorcorto_createChildtoNULL:If no mount is available to provide a unique id and a user does not provide an id,
corto_declareChild(and thuscorto_createChild) will fail.Default matching applies to finding a mount that can provide the id. For example, when the mount has a type filter, it will only be invoked when the user is trying to create an object of a matching type.
This behavior will only be invoked when the mount is configured to be a
SINK, since this is a feature that exclusively makes sense for objects that are created locally (a remote object already got its id from the remote data source).