@assert#28
Conversation
|
@StefanHenke This is now also ready for review with the release of 4.6.0 |
| end); | ||
|
|
||
| EndDate @assert: (case | ||
| when EndDate < BeginDate then error('ASSERT_ENDDATE_AFTER_BEGINDATE', null, (BeginDate, EndDate)) |
There was a problem hiding this comment.
in the JS variant, an additional check is used :
when exists Bookings [Flight.date < Travel.BeginDate] then 'ASSERT_BOOKINGS_IN_TRAVEL_PERIOD'
However, the JS variant does the check again on the Travel entity (https://github.com/capire/xtravels/blob/e89c2df28511de82a35e9da5433182d283388d9f/srv/travel-constraints.cds#L22C4-L22C98).
There was a problem hiding this comment.
This logic is covered by the assertion on Flight.date. I wouldn't duplicate these errors, as it leads to multiple errors with the same reason. I'd rather refer to the BeginDate/EndDate as additional targets, but I don't think this is necessary here.
| when date not between $self.Travel.BeginDate and $self.Travel.EndDate then 'ASSERT_BOOKINGS_IN_TRAVEL_PERIOD' | ||
| end); | ||
| } | ||
|
|
There was a problem hiding this comment.
taken from the JS variant:
| BookingDate @assert: (case | |
| when BookingDate > Travel.EndDate then 'ASSERT_NO_BOOKINGS_AFTER_TRAVEL' | |
| end); |
There was a problem hiding this comment.
I'd leave this out for now. The BookingDate is defaulted to "today". This makes it very impractical to play around with the application when creating new bookings, as all test data is in the past. We can maybe add it later on, but I don't think it shows any additional feature, so I would leave it out for practical reasons.
3 participants
No description provided.