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
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.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
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.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”.