Dynamic links over time constraint

[gjeusel]

Hey there,

I would like to create dynamic links over time. Meaning each link got a time interval validity from ts_start to ts_end.

To illustrate my case, let's say I'm a librarian and I got books people can borrow over a limited amount of time (15 days).
The same book can't be borrowed twice at the same time, hence I would like to prevent any link creation to a same book if there is an overlapping period.

How would I achieve such constraint ?

abstract link timesliced_link {
  property ts_start -> datetime { default := std::datetime_current() };
  property ts_end -> datetime { default := std::datetime_current() + cal::to_relative_duration(days := 15) };
}

type Book {
  required property title -> str;
}

type Reader {
  required property first_name -> str;
  required property last_name -> str;
  constraint exclusive on ((__subject__.first_name, __subject__.last_name));

  multi link borrowed_books extending timesliced_link -> Book {
    # Add a constraint on the subject which can't be borrowed twice at the same time:
    # constraint exclusive on (__subject__@source, ...? )
  }
}

[vpetrovykh]

This is an excellent question, but before I get to the meat of it allow me to comment on the setup overall.

While we're on the subject of constraints, I would like to address this first:

  required property first_name -> str;
  required property last_name -> str;
  constraint exclusive on ((__subject__.first_name, __subject__.last_name));

Usually you want to avoid any form of uniqueness constraint on actual human names, because you might legitimately have more than one "Jane Smith" or whatever other common name. In case of library example I would actually recommend going with the id.

Another note, this library scenario is a good case for using cal::local_date instead of std::datetime. Basically, libraries rarely care about specific time of day when the book is borrowed and returned, but rather a broad calendar date. Thus the following makes a bit more sense:

  property ts_start -> cal::local_date { 
    # Use whatever time zone is appropriate, which might be tricky if
    # this is geographically spread out, then you might need a more
    # specialized function
    default := cal::to_local_date(datetime_current(), 'EST');
  };
  property ts_end -> cal::local_date { 
    default := cal::to_local_date(datetime_current(), 'EST') + cal::to_relative_duration(days := 15) 
  };

[vpetrovykh]

Regarding the question about borrowed_books constraint, at the moment we don't have functions for comparing time intervals as you need here, so there's no exclusive constraint that would do exactly what you asked. However, is it actually what you need here? I understand that this library example might be a simplification or a proxy for something else, but I'll take it at face value. The real life limitation is that any physical book copy cannot be borrowed by more than one reader at a time. So a natural constraint would just be plain exclusive:

abstract link timesliced_link {
  property ts_start -> cal::local_date {
    # Use whatever time zone is appropriate, which might be tricky if
    # this is geographically spread out, then you might need a more
    # specialized function
    default := cal::to_local_date(datetime_current(), 'EST');
  };
  property ts_end -> cal::local_date {
    default := cal::to_local_date(datetime_current(), 'EST') + 
        cal::to_relative_duration(days := 15)
  };
}

type Book {
  required property title -> str;
}

type Reader {
  required property first_name -> str;
  required property last_name -> str;

  multi link borrowed_books extending timesliced_link -> Book {
    constraint exclusive;
  }
}

In practice it means that the system would only allow any given Book to be borrowed by one Reader at a time, regardless of the actual timestamps. The timestamps might be useful for other purposes.

If you want to keep a record of past borrowings, then I suggest the same system actual libraries use: keep a record on each Book, not the Reader. Or better yet, keep a separate Log:

type Log {
    required single link -> Reader;
    required single link -> Book;
    required property ts_start -> cal::local_date;
    required property ts_end -> cal::local_date;
}

The latter has the advantage of correctly expressing the situation where the same Reader borrows the same Book on multiple occasions.

You may want to also imitate real life libraries and have a waiting queue of readers who want to borrow the same book:

type WaitingQueue {
    required single link -> Reader;
    required single link -> Book;
    # This is actually denoting a moment in time when the reader asked
    # for a book, so datetime is appropriate datatype here.
    required property ts_requested -> datetime;
}

I hope that you find this answer helpful even though doing what you explicitly requested is not possible.

[vpetrovykh]

Relating this to the more general idea you're asking about, if the reason for wanting to forbid overlapping "borrowing" of the same thing is that the actual things being borrowed are unique, limited and can only have one user at a time, then perhaps a plain exclusive constraint together with a log will still end up serving the purpose you need by enforcing the constraints during the moment of borrowing and not on the log itself.

[gjeusel]

Thank you very much for the detailed explanations and improvements you suggested for the library case.
Yes indeed, keeping a Log for past activities might be a simpler solution for this scenario.

However, like you guessed, it is a proxy problem to my actual use case.
Do you foresee a near future where edgedb would allow this kind of contraint customisation ? By allowing the use of custom function in the exclusive ? Or will the triggers be appropriate for this ?

[vpetrovykh]

This has been informally discussed before and now we went ahead and formally created an issue for this and related problems: #3089. The specific solution may end up slightly different from the original write-up, but overall we intend to both introduce the time intervals and to make them usable with the exclusive constraint.

As for the timeline, it's hard to make specific promises yet, but a preliminary discussion seems to point to "sooner rather than later" because the feature is indeed useful and it looks like we have a good idea about the implementation.

Thanks again for bringing this up!