Hi @entzik ,
I thought the question was clear and I still stand by my comment that it’s akin to foreign keys; let me try to explain again what I mean.
You wanted to prohibit the creation of the Security
if the corresponding CodeReservationConfirmation
doesn’t exist. In RDBMS terms, if you think about Security
and CodeReservationConfirmation
as tables and of contracts instances as rows in those tables, you want to prohibit the creation of a new row in Security
if the reservation
column doesn’t point to the ID of an existing row in CodeReservationConfirmation
. A foreign key constraint would check that for you.
So far so good, DAML and DAML-based ledgers could be changed to check this for you reasonably easily at the creation time. The question is what happens later. If at some point after creating some Security
contract, let’s call it s
, the s.reservation
gets archived, should s
automatically be archived as well? That would correspond to ON DELETE CASCADE
. The problem is that this doesn’t play so well with DAML’s visibility constraints; it is possible that the stakeholders of s.reservation
don’t even know about the existence of s
.
What you can currently do instead is to add a fetch s.reservation
to every place where you use s
in an Update
. The caveat is that you would have to make your own provisions for archiving the s
, once the s.reservation
is gone.
IMO if there’s sufficient popular demand, this is something that we could also add some syntax sugar for (technically, it might be more than just syntax sugar, as we could make the Fetch a subaction of the Create, for example). The syntax sugar could also be extended to check an arbitrary relationship between s
and s.reservation
, as you’ll usually want to assert some kind of relation. We’d have to figure out how to do this best; if we’re already doing the fetch, then you probably want to be able to access the fields of s.reservation
without doing another fetch. @bernhard has some plans for adding what he calls “fat contracts” to DAML, which would combine the contract ID and the data; this could potentially be combined with the “auto-fetch”.