2023-08-08 00:29:14 +00:00
|
|
|
-- Deploy camper:edit_campsite_type to pg
|
|
|
|
-- requires: roles
|
|
|
|
-- requires: schema_camper
|
|
|
|
-- requires: campsite_type
|
|
|
|
-- requires: company
|
2024-01-29 02:38:11 +00:00
|
|
|
-- requires: campsite_type__check_in_out
|
|
|
|
-- requires: campsite_type__overflow_allowed
|
|
|
|
-- requires: campsite_type__ask_zone_preferences
|
2023-08-08 00:29:14 +00:00
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
set search_path to camper, public;
|
|
|
|
|
2024-01-31 22:06:45 +00:00
|
|
|
drop function if exists edit_campsite_type(uuid, integer, text, text, text, text, text, text, text, text, integer, boolean, boolean, boolean, boolean);
|
2024-01-14 23:28:34 +00:00
|
|
|
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
create or replace function edit_campsite_type(slug uuid, media_id integer, name text, spiel text, info text, facilities text, description text, additional_info text, check_in text, check_out text, max_campers integer, bookable_nights int4range, overflow_allowed boolean, ask_zone_preferences boolean, active boolean) returns uuid as
|
2023-08-08 00:29:14 +00:00
|
|
|
$$
|
|
|
|
update campsite_type
|
|
|
|
set name = edit_campsite_type.name
|
2023-10-12 16:47:08 +00:00
|
|
|
, spiel = xmlparse(content edit_campsite_type.spiel)
|
2023-08-08 00:29:14 +00:00
|
|
|
, description = xmlparse(content edit_campsite_type.description)
|
2023-10-13 11:40:48 +00:00
|
|
|
, info = xmlparse(content edit_campsite_type.info)
|
2024-01-14 23:28:34 +00:00
|
|
|
, additional_info = xmlparse(content edit_campsite_type.additional_info)
|
2024-01-22 19:19:19 +00:00
|
|
|
, check_in = edit_campsite_type.check_in
|
|
|
|
, check_out = edit_campsite_type.check_out
|
2023-10-13 11:40:48 +00:00
|
|
|
, facilities = xmlparse(content edit_campsite_type.facilities)
|
Add cover media to campsite types
This is the image that is shown at the home page, and maybe other pages
in the future. We can not use a static file because this image can be
changed by the customer, not us; just like name and description.
I decided to keep the actual media content in the database, but to copy
this file out to the file system the first time it is accessed. This is
because we are going to replicate the database to a public instance that
must show exactly the same image, but the customer will update the image
from the private instance, behind a firewall. We could also synchronize
the folder where they upload the images, the same way we will replicate,
but i thought that i would make the whole thing a little more brittle:
this way if it can replicate the update of the media, it is impossible
to not have its contents; dumping it to a file is to improve subsequent
requests to the same media.
I use the hex representation of the media’s hash as the URL to the
resource, because PostgreSQL’s base64 is not URL save (i.e., it uses
RFC2045’s charset that includes the forward slash[0]), and i did not
feel necessary write a new function just to slightly reduce the URLs’
length.
Before checking if the file exists, i make sure that the given hash is
an hex string, like i do for UUID, otherwise any other check is going
to fail for sure. I moved out hex.Valid function from UUID to check for
valid hex values, but the actual hash check is inside app/media because
i doubt it will be used outside that module.
[0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
|
|
|
, media_id = coalesce(edit_campsite_type.media_id, campsite_type.media_id)
|
2023-09-29 18:17:39 +00:00
|
|
|
, max_campers = edit_campsite_type.max_campers
|
2024-01-31 22:06:45 +00:00
|
|
|
, bookable_nights = edit_campsite_type.bookable_nights
|
2024-01-29 02:38:11 +00:00
|
|
|
, overflow_allowed = edit_campsite_type.overflow_allowed
|
|
|
|
, ask_zone_preferences = edit_campsite_type.ask_zone_preferences
|
2023-08-14 09:43:58 +00:00
|
|
|
, active = edit_campsite_type.active
|
2023-08-08 00:29:14 +00:00
|
|
|
where slug = edit_campsite_type.slug
|
|
|
|
returning slug;
|
|
|
|
$$
|
|
|
|
language sql
|
|
|
|
;
|
|
|
|
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
revoke execute on function edit_campsite_type(uuid, integer, text, text, text, text, text, text, text, text, integer, int4range, boolean, boolean, boolean) from public;
|
|
|
|
grant execute on function edit_campsite_type(uuid, integer, text, text, text, text, text, text, text, text, integer, int4range, boolean, boolean, boolean) to admin;
|
2023-08-08 00:29:14 +00:00
|
|
|
|
|
|
|
commit;
|