Allow many campsites for each reservation
This is actually only used for plots, but, of course, it means that
every booking now can potentially have many booked campsites, and have
to create a relation for it.
I now have a conundrum regarding stay dates: i need them to be in the
same table as the campsite_id, because constraints only work on a single
relation and without the dates i can not make sure that i am not
overbooking a given campsite; but, on the other hand, all campsites
under the same booking must be for the same dates.
Where does stay belong, then? In booking or booking_campsite? If in
booking then i can not have a constraint that most assuredly will bite
me in the back, but if in booking_campsite then each campsite could
potentially have different dates.
As far as i can see, i can not use a exclude constraint with <> for
dates in booking_campsite to ensure that all rows with the same
booking_id have the same stay (i.e., exclude those that have a different
stay for the same booking_id).
For now, the say is in **both** relations: in booking, because i need it
when it is a prebooking, at least, and in booking_campsite for the
aforementioned constraint requirements.
Will this come back and bite me? Yes, it will. But what can i do?
2024-04-21 19:28:41 +00:00
|
|
|
-- Test booking_campsite
|
|
|
|
set client_min_messages to warning;
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
select plan(25);
|
|
|
|
|
|
|
|
set search_path to camper, public;
|
|
|
|
|
|
|
|
select has_table('booking_campsite');
|
|
|
|
select has_pk('booking_campsite');
|
|
|
|
select col_is_pk('booking_campsite', array['booking_id', 'campsite_id', 'stay']);
|
|
|
|
select table_privs_are('booking_campsite', 'guest', array[]::text[]);
|
|
|
|
select table_privs_are('booking_campsite', 'employee', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
|
|
|
|
select table_privs_are('booking_campsite', 'admin', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
|
|
|
|
select table_privs_are('booking_campsite', 'authenticator', array[]::text[]);
|
|
|
|
|
|
|
|
select has_column('booking_campsite', 'booking_id');
|
|
|
|
select col_is_fk('booking_campsite', 'booking_id');
|
|
|
|
select fk_ok('booking_campsite', 'booking_id', 'booking', 'booking_id');
|
|
|
|
select col_type_is('booking_campsite', 'booking_id', 'integer');
|
|
|
|
select col_not_null('booking_campsite', 'booking_id');
|
|
|
|
select col_hasnt_default('booking_campsite', 'booking_id');
|
|
|
|
|
|
|
|
select has_column('booking_campsite', 'campsite_id');
|
|
|
|
select col_is_fk('booking_campsite', 'campsite_id');
|
|
|
|
select fk_ok('booking_campsite', 'campsite_id', 'campsite', 'campsite_id');
|
|
|
|
select col_type_is('booking_campsite', 'campsite_id', 'integer');
|
|
|
|
select col_not_null('booking_campsite', 'campsite_id');
|
|
|
|
select col_hasnt_default('booking_campsite', 'campsite_id');
|
|
|
|
|
|
|
|
select has_column('booking_campsite', 'stay');
|
|
|
|
select col_type_is('booking_campsite', 'stay', 'daterange');
|
|
|
|
select col_not_null('booking_campsite', 'stay');
|
|
|
|
select col_hasnt_default('booking_campsite', 'stay');
|
|
|
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
truncate booking_campsite cascade;
|
|
|
|
truncate booking cascade;
|
|
|
|
truncate campsite_type cascade;
|
|
|
|
truncate media cascade;
|
|
|
|
truncate media_content cascade;
|
|
|
|
truncate company cascade;
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, rtc_number, tourist_tax, tourist_tax_max_days, country_code, currency_code, default_lang_tag)
|
|
|
|
values (2, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 60, 7, 'ES', 'EUR', 'ca')
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into media_content (media_type, bytes)
|
|
|
|
values ('image/x-xpixmap', 'static char *s[]={"1 1 1 1","a c #ffffff","a"};')
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into media (media_id, company_id, original_filename, content_hash)
|
|
|
|
values (6, 2, 'cover2.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into campsite_type (campsite_type_id, company_id, name, media_id, max_campers, bookable_nights)
|
|
|
|
values (10, 2, 'Wooden lodge', 6, 7, '[1, 7]')
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into campsite (campsite_id, company_id, label, campsite_type_id)
|
|
|
|
values (12, 2, 'A', 10)
|
|
|
|
, (14, 2, 'B', 10)
|
|
|
|
, (16, 2, 'C', 10)
|
|
|
|
;
|
|
|
|
|
“Finish” the new booking form
Had to bring the same fields that i have for a payment to booking,
except that some of those should be nullable, because it is unreasonable
to ask front desk to gather all customer data when they have a booking
via phone, for instance.
Therefore, i can not take advantage of the validation for customer data
that i use in the public-facing form, but, fortunately, most of the
validations where in separated functions, thus only had to rewrite that
one for this case.
I already have to create a booking from a payment, when receiving a
payment from the public instance, thus i made that function and reused
it here. Then i “overwrite” the newly created pre-booking with the
customer data from the form, and set is as confirmed, as we do not see
any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
|
|
|
insert into booking (booking_id, company_id, campsite_type_id, holder_name, stay, number_dogs, acsi_card, currency_code, zone_preferences, subtotal_nights, number_adults, subtotal_adults, number_teenagers, subtotal_teenagers, number_children, subtotal_children, subtotal_dogs, subtotal_tourist_tax, total)
|
|
|
|
values (18, 2, 10, 'Holder 2', daterange('2024-01-18', '2024-01-29'), 0, false, 'EUR', '', 0, 1, 0, 0, 0, 0, 0, 0, 0, 0)
|
|
|
|
, (20, 2, 10, 'Holder 4', daterange('2024-01-28', '2024-01-29'), 0, false, 'EUR', '', 0, 1, 0, 0, 0, 0, 0, 0, 0, 0)
|
Allow many campsites for each reservation
This is actually only used for plots, but, of course, it means that
every booking now can potentially have many booked campsites, and have
to create a relation for it.
I now have a conundrum regarding stay dates: i need them to be in the
same table as the campsite_id, because constraints only work on a single
relation and without the dates i can not make sure that i am not
overbooking a given campsite; but, on the other hand, all campsites
under the same booking must be for the same dates.
Where does stay belong, then? In booking or booking_campsite? If in
booking then i can not have a constraint that most assuredly will bite
me in the back, but if in booking_campsite then each campsite could
potentially have different dates.
As far as i can see, i can not use a exclude constraint with <> for
dates in booking_campsite to ensure that all rows with the same
booking_id have the same stay (i.e., exclude those that have a different
stay for the same booking_id).
For now, the say is in **both** relations: in booking, because i need it
when it is a prebooking, at least, and in booking_campsite for the
aforementioned constraint requirements.
Will this come back and bite me? Yes, it will. But what can i do?
2024-04-21 19:28:41 +00:00
|
|
|
;
|
|
|
|
|
|
|
|
insert into booking_campsite (booking_id, campsite_id, stay)
|
|
|
|
values (18, 12, daterange('2024-01-18', '2024-01-29'))
|
|
|
|
;
|
|
|
|
|
|
|
|
select lives_ok(
|
2024-04-21 19:57:34 +00:00
|
|
|
$$ insert into booking_campsite (booking_id, campsite_id, stay) values (18, 14, daterange('2024-01-18', '2024-01-29')) $$,
|
Allow many campsites for each reservation
This is actually only used for plots, but, of course, it means that
every booking now can potentially have many booked campsites, and have
to create a relation for it.
I now have a conundrum regarding stay dates: i need them to be in the
same table as the campsite_id, because constraints only work on a single
relation and without the dates i can not make sure that i am not
overbooking a given campsite; but, on the other hand, all campsites
under the same booking must be for the same dates.
Where does stay belong, then? In booking or booking_campsite? If in
booking then i can not have a constraint that most assuredly will bite
me in the back, but if in booking_campsite then each campsite could
potentially have different dates.
As far as i can see, i can not use a exclude constraint with <> for
dates in booking_campsite to ensure that all rows with the same
booking_id have the same stay (i.e., exclude those that have a different
stay for the same booking_id).
For now, the say is in **both** relations: in booking, because i need it
when it is a prebooking, at least, and in booking_campsite for the
aforementioned constraint requirements.
Will this come back and bite me? Yes, it will. But what can i do?
2024-04-21 19:28:41 +00:00
|
|
|
'Can insert a new campsite booking for the same range as another.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select throws_ok(
|
|
|
|
$$ insert into booking_campsite (booking_id, campsite_id, stay) values (20, 14, daterange('2024-01-28', '2024-01-29')) $$,
|
|
|
|
'23P01', 'conflicting key value violates exclusion constraint "booking_campsite_campsite_id_stay_excl"',
|
|
|
|
'Can not insert a new booking for the same campsite if the dates overlap.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select *
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
|