Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
-- m4_changequote(`[[', `]]')
2023-07-27 16:52:01 +00:00
begin ;
set search_path to camper , auth , public ;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table auth . " user " alter column user_id restart with 42 ;
2023-10-03 19:11:10 +00:00
insert into auth . " user " ( email , name , password , lang_tag )
values ( ' demo@camper ' , ' Demo User ' , ' demo ' , ' ca ' )
, ( ' admin@camper ' , ' Demo Admin ' , ' admin ' , ' ca ' )
2023-07-27 16:52:01 +00:00
;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table company alter column company_id restart with 52 ;
2023-07-31 16:21:29 +00:00
insert into company ( slug , business_name , vatin , trade_name , phone , email , web , address , city , province , postal_code , country_code , currency_code , default_lang_tag , legal_disclaimer )
2023-10-06 17:33:44 +00:00
values ( ' 09184122-b276-4be2-9553-e4bbcbafe40d ' , ' El pont de Llierca, S.L. ' , ' ESB17377656 ' , ' Càmping Montagut ' , parse_packed_phone_number ( ' 661 673 057 ' , ' ES ' ) , ' info@campingmontagut.com ' , ' https://campingmontagut.com/ ' , ' Ctra. de Sadernes, Km 2 ' , ' Montagut i Oix ' , ' Girona ' , ' 17855 ' , ' ES ' , ' EUR ' , ' ca ' , ' El pont de Llierca, S.L. és responsable del tractament de les seves dades d’ ’ ' ) ;
2023-07-29 02:25:56 +00:00
Use HTTP Host to establish the request’s company
We made the decision that this application will also serve the public
pages to guests and customers, to avoid the overhead of having to
synchronize all data between this application and a bespoke WordPress
plugin.
That means that i no longer can have a /company/slug in the URL to know
which company the request is for, not only because it looks ugly but
because guest users do not have a “main company”—or any company
whatsoever.
Since the public-facing web is going to be served through a valid DNS
domain, and all companies are going to have a different domain, i
realized this is enough: i only had to add a relation of company and
their hosts. The same company can have many hosts for staging servers
or to separate the administration and public parts, for instance.
With change, the company is already known from the first handler, and
can pass it down to all the others, not only the handlers under
/company/slug/whatever. And i no longer need the companyURL function,
as there is no more explicit company in the URL.
Even though template technically does not need the template, as it only
contains the ID —the rest of the data is in a relation inaccessible to
guests for now—, but i left the parameter just in case later on i need
the decimal digits or currency symbol for whatever reason.
2023-08-03 18:21:21 +00:00
insert into company_host ( company_id , host )
values ( 52 , ' localhost:8080 ' )
, ( 52 , ' camper.tandem.ws ' )
;
Add the contact page, containing a map with the company location
I was not sure whether to use PostGIS to store the GPS location of the
company, as i am sure i will only use that point just to show the map.
However, just in case, it is not a big deal.
There is no way to change that from the administration pages for now,
because of time constraints, and it is very unlikely that they will
change the campgrounds’ location in the near future.
The location is in a separate table because i did not want to have to
change every test file, to be honest, but this also makes the map
“optional” without the need for NULL values.
I added the contact address to every public page because the new design
adds it to the footer, so i will be needing it everywhere, just like the
menu.
2023-10-06 19:21:00 +00:00
insert into company_geography ( company_id , geog )
values ( 52 , ' SRID=4326;POINT(2.598825853208973 42.24256146290889) ' )
;
Move the user role down to company_user relation
I was starting to add the public page for campsite types, creating more
granular row-level security policies for select, insert, update, and
delete, because now the guest users needed to SELECT them and they have
no related company to filter the rows with. Suddenly, i realized that
the role was wrong in the user relation: a user can be an admin to one
company, and employee to another, and guess to yet another company;
the role should be in the company_user relation instead.
That means that to know the role to set to, the user alone is not enough
and have to know the company as well. Had to change all the
cookie-related function to accept also the company’s host name, as this
is the information that the Go application has.
2023-08-08 00:22:16 +00:00
insert into company_user ( company_id , user_id , role )
values ( 52 , 42 , ' employee ' )
, ( 52 , 43 , ' admin ' )
2023-07-29 02:25:56 +00:00
;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table media alter column media_id restart with 62 ;
Manage all media uploads in a single place
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
select add_media ( 52 , ' plots.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/plots.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' safari_tents.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/safari_tents.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' bungalows.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/bungalows.avif]]) ' , ' base64 ' ) ) ;
2023-10-06 16:53:44 +00:00
select add_media ( 52 , ' bungalows_premium.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/bungalows_premium.avif]]) ' , ' base64 ' ) ) ;
Manage all media uploads in a single place
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
select add_media ( 52 , ' wooden_lodges.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/wooden_lodges.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel0.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel0.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel1.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel1.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel2.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel2.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel3.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel3.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel4.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel4.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel5.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel5.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel6.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel6.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel7.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel7.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' home_carousel8.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel8.jpg]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' services_carousel0.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/services_carousel0.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' services_carousel1.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/services_carousel1.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' services_carousel2.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/services_carousel2.avif]]) ' , ' base64 ' ) ) ;
select add_media ( 52 , ' services_carousel3.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/services_carousel3.avif]]) ' , ' base64 ' ) ) ;
Make home page’s carousel manageable via the database
I debated with myself whether to create the home_carousel relation or
rather if it would be better to have a single carousel relation for all
pages. However, i thought that it would be actually harder to maintain
a single relation because i would need an additional column to tell one
carrousel from another, and what would that column be? An enum? A
foreign key to another relation? home_carousel carries no such issues.
I was starting to duplicate logic all over the packages, such as the
way to encode media paths or “localization” (l10n) input fields.
Therefore, i refactorized them.
In the case of media path, i added a function that accepts rows of
media, because always need the same columns from the row, and it was
yet another repetition if i needed to pass them all the time. Plus,
these kind of functions can be called as `table.function`, that make
them look like columns from the table; if PostgreSQL implemented virtual
generated columns, i would have used that instead.
I am not sure whether that media_path function can be immutable. An
immutable function is “guaranteed to return the same results given the
same arguments forever”, which would be true if the inputs where the
hash and the original_filename columns, instead of the whole rows, but
i left it as static because i did not know whether PostgreSQL interprets
the “same row but with different values” as a different input. That is,
whether PostgreSQL’s concept of row is the actual tuple or the space
that has a rowid, irrespective of contents; in the latter case, the
function can not be immutable. Just to be in the safe side, i left it
stable.
The home page was starting to grow a bit too much inside the app
package, new that it has its own admin handler, and moved it all to a
separate package.
2023-09-14 23:05:38 +00:00
;
insert into home_carousel ( media_id , caption )
2023-10-06 16:53:44 +00:00
values ( 67 , ' Volcà de Santa Margarida ' )
, ( 68 , ' Gorga fosca Sadernes ' )
, ( 69 , ' Castellfollit de la Roca ' )
, ( 70 , ' Besalú ' )
, ( 71 , ' Santa Pau ' )
, ( 72 , ' Banyoles ' )
, ( 73 , ' Girona ' )
, ( 74 , ' Costa Brava ' )
, ( 75 , ' Barcelona ' )
Make home page’s carousel manageable via the database
I debated with myself whether to create the home_carousel relation or
rather if it would be better to have a single carousel relation for all
pages. However, i thought that it would be actually harder to maintain
a single relation because i would need an additional column to tell one
carrousel from another, and what would that column be? An enum? A
foreign key to another relation? home_carousel carries no such issues.
I was starting to duplicate logic all over the packages, such as the
way to encode media paths or “localization” (l10n) input fields.
Therefore, i refactorized them.
In the case of media path, i added a function that accepts rows of
media, because always need the same columns from the row, and it was
yet another repetition if i needed to pass them all the time. Plus,
these kind of functions can be called as `table.function`, that make
them look like columns from the table; if PostgreSQL implemented virtual
generated columns, i would have used that instead.
I am not sure whether that media_path function can be immutable. An
immutable function is “guaranteed to return the same results given the
same arguments forever”, which would be true if the inputs where the
hash and the original_filename columns, instead of the whole rows, but
i left it as static because i did not know whether PostgreSQL interprets
the “same row but with different values” as a different input. That is,
whether PostgreSQL’s concept of row is the actual tuple or the space
that has a rowid, irrespective of contents; in the latter case, the
function can not be immutable. Just to be in the safe side, i left it
stable.
The home page was starting to grow a bit too much inside the app
package, new that it has its own admin handler, and moved it all to a
separate package.
2023-09-14 23:05:38 +00:00
;
insert into home_carousel_i18n ( media_id , lang_tag , caption )
2023-10-06 16:53:44 +00:00
values ( 67 , ' en ' , ' Santa Margarida volcano ' )
, ( 67 , ' es ' , ' Volcán de Santa Margarida ' )
, ( 68 , ' en ' , ' Sadernes dark gorge ' )
, ( 68 , ' es ' , ' Piletón oscuro Sadernes ' )
Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
;
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
insert into services_carousel ( media_id , caption )
2023-10-06 16:53:44 +00:00
values ( 76 , ' La Garrotxa ' )
, ( 77 , ' Tenda ' )
, ( 78 , ' Parceŀles ' )
, ( 79 , ' Hamaca ' )
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
, ( 63 , ' Safari Tents ' )
;
insert into services_carousel_i18n ( media_id , lang_tag , caption )
2023-10-06 16:53:44 +00:00
values ( 77 , ' en ' , ' Tent ' )
, ( 77 , ' es ' , ' Tenda ' )
, ( 78 , ' en ' , ' Plots ' )
, ( 78 , ' es ' , ' Parcelas ' )
, ( 79 , ' en ' , ' Hammock ' )
, ( 79 , ' es ' , ' Amaca ' )
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
, ( 63 , ' en ' , ' Safari Tents ' )
, ( 63 , ' es ' , ' Tiendas Safari ' )
;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table campsite_type alter column campsite_type_id restart with 72 ;
2023-09-29 18:17:39 +00:00
select add_campsite_type ( 52 , 62 , ' Parceŀles ' , ' ' , 6 , true ) ;
select add_campsite_type ( 52 , 63 , ' Safari Tents ' , ' ' , 6 , false ) ;
select add_campsite_type ( 52 , 64 , ' Bungalous ' , ' ' , 5 , false ) ;
2023-10-06 16:53:44 +00:00
select add_campsite_type ( 52 , 65 , ' Bungalous prèmium ' , ' ' , 5 , false ) ;
select add_campsite_type ( 52 , 66 , ' Cabanes de fusta ' , ' ' , 5 , false ) ;
2023-09-29 18:17:39 +00:00
2023-09-12 18:20:23 +00:00
insert into campsite_type_i18n ( campsite_type_id , lang_tag , name , description )
values ( 72 , ' en ' , ' Plots ' , ' ' )
, ( 72 , ' es ' , ' Parcelas ' , ' ' )
, ( 73 , ' en ' , ' Safari Tents ' , ' ' )
, ( 73 , ' es ' , ' Tiendas Safari ' , ' ' )
, ( 74 , ' en ' , ' Bungalows ' , ' ' )
, ( 74 , ' es ' , ' Bungalós ' , ' ' )
2023-10-06 16:53:44 +00:00
, ( 75 , ' en ' , ' Bungalows premium ' , ' ' )
, ( 75 , ' es ' , ' Bungalós prémium ' , ' ' )
, ( 76 , ' en ' , ' Wooden Lodges ' , ' ' )
, ( 76 , ' es ' , ' Cabañas de madera ' , ' ' )
2023-09-12 18:20:23 +00:00
;
Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table campsite alter column campsite_id restart with 82 ;
Add campsite map in SVG
I intend to use the same SVG file for customers and employees, so i had
to change Oriol’s design to add a class to layers that are supposed to
be only for customers, like trees. These are hidden in the admin area.
I understood that customers and employees have to click on a campsite to
select it, and then they can book or whatever they need to do to them.
Since customers and employees most certainly will need to have different
listeners on campsites, i decided to add the link with JavaScript. To
do so, i need a custom XML attribute with the campsite’s identifier.
Since i have seen that all campsites have a label, i changed the
“identifier” to the unique combination (company_id, label). The
company_id is there because different companies could have the same
label; i left the campsite_id primary key for foreign constraints.
In this case, as a test, i add an <a> element to the campsite with a
link to edit it; we’ll discuss with Oriol what exactly it needs to do.
However, the original design had the labels in a different layer, that
interfered with the link, as the numbers must be above the path and
the link must wrap the path in order to “inherit” its shape. I had no
other recourse than to move the labels in the same layer as the paths’.
2023-09-24 01:17:13 +00:00
select add_campsite ( 72 , ' 2 ' ) ;
select add_campsite ( 72 , ' 3 ' ) ;
select add_campsite ( 72 , ' 4 ' ) ;
select add_campsite ( 72 , ' 5 ' ) ;
select add_campsite ( 72 , ' 6 ' ) ;
select add_campsite ( 72 , ' 7 ' ) ;
select add_campsite ( 72 , ' 8 ' ) ;
select add_campsite ( 72 , ' 9 ' ) ;
select add_campsite ( 72 , ' 10 ' ) ;
select add_campsite ( 72 , ' 11 ' ) ;
select add_campsite ( 72 , ' 12 ' ) ;
select add_campsite ( 72 , ' 14 ' ) ;
select add_campsite ( 72 , ' 15 ' ) ;
select add_campsite ( 72 , ' 16 ' ) ;
select add_campsite ( 72 , ' 17 ' ) ;
select add_campsite ( 72 , ' 18 ' ) ;
select add_campsite ( 72 , ' 19 ' ) ;
select add_campsite ( 72 , ' 20 ' ) ;
select add_campsite ( 72 , ' 21 ' ) ;
select add_campsite ( 72 , ' 22 ' ) ;
select add_campsite ( 72 , ' 23 ' ) ;
select add_campsite ( 72 , ' 24 ' ) ;
select add_campsite ( 72 , ' 25 ' ) ;
select add_campsite ( 72 , ' 26 ' ) ;
select add_campsite ( 72 , ' 27 ' ) ;
select add_campsite ( 72 , ' 28 ' ) ;
select add_campsite ( 72 , ' 29 ' ) ;
select add_campsite ( 72 , ' 42 ' ) ;
select add_campsite ( 72 , ' 43 ' ) ;
select add_campsite ( 72 , ' 44 ' ) ;
select add_campsite ( 72 , ' 45 ' ) ;
select add_campsite ( 72 , ' 46 ' ) ;
select add_campsite ( 72 , ' 47 ' ) ;
select add_campsite ( 72 , ' 48 ' ) ;
select add_campsite ( 72 , ' 50 ' ) ;
select add_campsite ( 72 , ' 51 ' ) ;
select add_campsite ( 72 , ' 52 ' ) ;
select add_campsite ( 72 , ' 53 ' ) ;
select add_campsite ( 72 , ' 54 ' ) ;
select add_campsite ( 72 , ' 55 ' ) ;
select add_campsite ( 72 , ' 56 ' ) ;
select add_campsite ( 72 , ' 57 ' ) ;
select add_campsite ( 72 , ' 58 ' ) ;
select add_campsite ( 72 , ' 59 ' ) ;
select add_campsite ( 72 , ' 60 ' ) ;
select add_campsite ( 72 , ' 61 ' ) ;
select add_campsite ( 72 , ' 62 ' ) ;
select add_campsite ( 72 , ' 63 ' ) ;
select add_campsite ( 72 , ' 64 ' ) ;
select add_campsite ( 72 , ' 65 ' ) ;
select add_campsite ( 72 , ' 69 ' ) ;
select add_campsite ( 72 , ' 70 ' ) ;
select add_campsite ( 72 , ' 71 ' ) ;
select add_campsite ( 72 , ' 72 ' ) ;
select add_campsite ( 72 , ' 73 ' ) ;
select add_campsite ( 72 , ' 74 ' ) ;
select add_campsite ( 72 , ' 75 ' ) ;
select add_campsite ( 72 , ' 76 ' ) ;
select add_campsite ( 72 , ' 77 ' ) ;
2023-09-25 10:51:11 +00:00
select add_campsite ( 73 , ' 78 ' ) ;
Add campsite map in SVG
I intend to use the same SVG file for customers and employees, so i had
to change Oriol’s design to add a class to layers that are supposed to
be only for customers, like trees. These are hidden in the admin area.
I understood that customers and employees have to click on a campsite to
select it, and then they can book or whatever they need to do to them.
Since customers and employees most certainly will need to have different
listeners on campsites, i decided to add the link with JavaScript. To
do so, i need a custom XML attribute with the campsite’s identifier.
Since i have seen that all campsites have a label, i changed the
“identifier” to the unique combination (company_id, label). The
company_id is there because different companies could have the same
label; i left the campsite_id primary key for foreign constraints.
In this case, as a test, i add an <a> element to the campsite with a
link to edit it; we’ll discuss with Oriol what exactly it needs to do.
However, the original design had the labels in a different layer, that
interfered with the link, as the numbers must be above the path and
the link must wrap the path in order to “inherit” its shape. I had no
other recourse than to move the labels in the same layer as the paths’.
2023-09-24 01:17:13 +00:00
select add_campsite ( 72 , ' 79 ' ) ;
select add_campsite ( 72 , ' 80 ' ) ;
select add_campsite ( 72 , ' 81 ' ) ;
select add_campsite ( 72 , ' 82 ' ) ;
select add_campsite ( 72 , ' 83 ' ) ;
2023-10-06 16:53:44 +00:00
select add_campsite ( 76 , ' 84 ' ) ;
select add_campsite ( 76 , ' 85 ' ) ;
Add campsite map in SVG
I intend to use the same SVG file for customers and employees, so i had
to change Oriol’s design to add a class to layers that are supposed to
be only for customers, like trees. These are hidden in the admin area.
I understood that customers and employees have to click on a campsite to
select it, and then they can book or whatever they need to do to them.
Since customers and employees most certainly will need to have different
listeners on campsites, i decided to add the link with JavaScript. To
do so, i need a custom XML attribute with the campsite’s identifier.
Since i have seen that all campsites have a label, i changed the
“identifier” to the unique combination (company_id, label). The
company_id is there because different companies could have the same
label; i left the campsite_id primary key for foreign constraints.
In this case, as a test, i add an <a> element to the campsite with a
link to edit it; we’ll discuss with Oriol what exactly it needs to do.
However, the original design had the labels in a different layer, that
interfered with the link, as the numbers must be above the path and
the link must wrap the path in order to “inherit” its shape. I had no
other recourse than to move the labels in the same layer as the paths’.
2023-09-24 01:17:13 +00:00
select add_campsite ( 72 , ' 89 ' ) ;
select add_campsite ( 72 , ' 90 ' ) ;
select add_campsite ( 72 , ' 91 ' ) ;
select add_campsite ( 72 , ' 92 ' ) ;
select add_campsite ( 72 , ' 93 ' ) ;
select add_campsite ( 72 , ' 94 ' ) ;
select add_campsite ( 72 , ' 95 ' ) ;
select add_campsite ( 72 , ' 96 ' ) ;
select add_campsite ( 72 , ' 97 ' ) ;
select add_campsite ( 72 , ' 98 ' ) ;
select add_campsite ( 72 , ' B1 ' ) ;
select add_campsite ( 72 , ' D1 ' ) ;
select add_campsite ( 72 , ' D2 ' ) ;
select add_campsite ( 72 , ' D3 ' ) ;
select add_campsite ( 72 , ' D4 ' ) ;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table service alter column service_id restart with 82 ;
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
insert into service ( company_id , icon_name , name , description )
values ( 52 , ' information ' , ' Informació ' , ' <p>A la recepció l’ ' )
, ( 52 , ' wifi ' , ' WiFi ' , ' <p>Un 80 ’ ’ ' )
, ( 52 , ' restaurant ' , ' Bar & Tapes ' , ' <p>Oberts:</p><ul><li>De l’ ’ ' )
, ( 52 , ' store ' , ' Botiga ' , ' <p>Oberta a diari.</p><p>Venda de pa del dia per encàrrec.</p> ' )
, ( 52 , ' wheelchair ' , ' Accessibilitat ' , ' <p>Piscines i serveis del càmping adaptats a persones amb mobilitat reduïda.</p> ' )
, ( 52 , ' toilet ' , ' Lavabos ' , ' <p>Ubicació central i pràctica. Nets i ben mantinguts.</p> ' )
, ( 52 , ' shower ' , ' Dutxa ' , ' <p>Aigua calenta, sense fitxes.</p> ' )
, ( 52 , ' baby ' , ' Bany per nadons ' , ' <p>Bany individual per nadons, amb banyera i canviador.</p> ' )
, ( 52 , ' pool ' , ' Piscina ' , ' <p>Piscina per adults i piscina infantil.</p><p><em>(Piscines amb aigua salada.)</em></p> ' )
, ( 52 , ' campfire ' , ' Barbacoa ' , ' <p>Trobareu una barbacoa comunitària de carbó o la possibilitat de llogar una barbacoa de gas (no es pot fer servir llenya o carbó en les parcel·les).</p> ' )
, ( 52 , ' rv ' , ' Estació servei per autocaravanes ' , ' <p>Situada a l’ ' )
, ( 52 , ' castle ' , ' Zona de jocs ' , ' <p>Una zona central pels més menuts.</p> ' )
, ( 52 , ' ball ' , ' Camp d’ ' , ' <p>Amb camp de futbol, voley, tenis-taula i espai per jugar.</p> ' )
, ( 52 , ' puzzle ' , ' Sala de jocs i televisió ' , ' <p>Una sala pels dies de mal temps.</p> ' )
, ( 52 , ' washer ' , ' Rentadores i assecadores ' , ' <p>Als safareigs del càmping hi ha dues rentadores i una assecadora que funcionen amb fitxes.</p> ' )
, ( 52 , ' fridge ' , ' Lloguer de neveres ' , ' <p>Possibilitat de llogar neveres per estades llargues amb <a href="https://www.rentit.es/ca/portal/productes/42/">Rent It</a>.</p> ' )
;
insert into service_i18n ( service_id , lang_tag , name , description )
values ( 82 , ' en ' , ' Information ' , ' <p>At reception we will inform you of what you can do from the campsite itself or in the surrounding area.</p> ' )
, ( 82 , ' es ' , ' Información ' , ' <p>A recepción le informaremos de qué puede hacer en el camping o por los alrededores.</p> ' )
, ( 83 , ' en ' , ' WiFi ' , ' <p>80 ' )
, ( 83 , ' es ' , ' WiFi ' , ' <p>Un 80 ' )
, ( 84 , ' en ' , ' Bar & Tapas ' , ' <p>Open:</p><ul><li>From 07/01 to 08/28: everyday</li><li>From April to September: weekends and holidays</li></ul> ' )
, ( 84 , ' es ' , ' Bar & Tapas ' , ' <p>Abierto:</p><ul><li>Del 01/07 al 28/08: cada día</li><li>De abril a setiembre: fines de semana y puentes</li></ul> ' )
, ( 85 , ' en ' , ' Shop ' , ' <p>Open daily</p><p>Sale of daily bread to order.</p> ' )
, ( 85 , ' es ' , ' Tienda ' , ' <p>Abierta a diario.</p><p>Venta de pan del día por encargo.</p> ' )
, ( 86 , ' en ' , ' Accessibility ' , ' <p>Swimming pools and campsite services adapted to people with reduced mobility.</p> ' )
, ( 86 , ' es ' , ' Acesibilidad ' , ' <p>Piscinas y servicios del camping adaptados a personas con mobilidad reducida.</p> ' )
, ( 87 , ' en ' , ' Toilets ' , ' <p>Central and practical location. Clean and well maintained.</p> ' )
, ( 87 , ' es ' , ' Lavabos ' , ' <p>Ubicación central y práctica. Limpios y bien mantenidos.</p> ' )
, ( 88 , ' en ' , ' Showers ' , ' <p>Hot water, no tokens.</p> ' )
, ( 88 , ' es ' , ' Duchas ' , ' <p>Agua caliente, sin fichas.</p> ' )
, ( 89 , ' en ' , ' Baby baths ' , ' <p>Individual bathroom for babies, with bathtub and changing table.</p> ' )
, ( 89 , ' es ' , ' Baño para bebés ' , ' <p>Baños individuales para bebés, con bañera y cambiador.</p> ' )
, ( 90 , ' en ' , ' Swimming pool ' , ' <p>Adult pool and children’ ' )
, ( 90 , ' es ' , ' Piscina ' , ' <p>Piscina para adultos y piscina infantil.</p><p><em>(Piscinas con agua salada.)</em></p> ' )
, ( 91 , ' en ' , ' Barbecue ' , ' <p>You will find a communal charcoal barbecue or the possibility of renting a gas barbecue (no wood or charcoal can be used on the plots).</p> ' )
, ( 91 , ' es ' , ' Barbacoa ' , ' <p>Encontraréis una barbacoa comunitaria de carbón o la posibilidad de alquilar una barbacoa de gas (no se puede utilizar leña o carbón en las parcelas).</p> ' )
, ( 92 , ' en ' , ' RV service station ' , ' <p>Located at the entrance of the campsite.</p> ' )
, ( 92 , ' es ' , ' Estación servicio para autocaravanas ' , ' <p>Situada en la entrada del camping.</p> ' )
, ( 93 , ' en ' , ' Play area ' , ' <p>A central area for the little ones.</p> ' )
, ( 93 , ' es ' , ' Zona de juegos ' , ' <p>Una zona central para los más pequeños.</p> ' )
, ( 94 , ' en ' , ' Sports area ' , ' <p>With football field, volleyball, table tennis and room to play.</p> ' )
, ( 94 , ' es ' , ' Campo de deporte ' , ' <p>Con campo de fútbol, voley, pimpón i espacio para jugar.</p> ' )
, ( 95 , ' en ' , ' Games and television room ' , ' <p>A room for bad weather days.</p> ' )
, ( 95 , ' es ' , ' Sala de juegos y televisión ' , ' <p>Una sala para los días de mal tiempo.</p> ' )
, ( 96 , ' en ' , ' Washing machines and dryers ' , ' <p>There are two token-operated washing machines and a dryer in the campsite’ ' )
, ( 96 , ' es ' , ' Lavadora y secadoras ' , ' <p>A los lavaderos del camping hay dos lavadoras y una secadora que funcionana con fichas.</p> ' )
, ( 97 , ' en ' , ' Fridge rental ' , ' <p>Possibility to rent refrigerators for long stays with <a href="https://www.rentit.es/en/portal/productes/42/">Rent It</a>.</p> ' )
, ( 97 , ' es ' , ' Alquiler de neveras ' , ' <p>Posibilidad de alquilar neveras para estancias largas con <a href="https://www.rentit.es/es/portal/productes/42/">Rent It</a>.</p> ' )
;
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
alter table season alter column season_id restart with 92 ;
2023-09-26 16:54:20 +00:00
select add_season ( 52 , ' Temporada alta ' , ' #ff926c ' ) ;
select add_season ( 52 , ' Temporada mitjana ' , ' #ffe37f ' ) ;
select add_season ( 52 , ' Temporada baixa ' , ' #00aa7d ' ) ;
2023-10-03 19:14:37 +00:00
insert into season_i18n ( season_id , lang_tag , name )
values ( 92 , ' en ' , ' Peak season ' )
, ( 92 , ' es ' , ' Temporada alta ' )
, ( 93 , ' en ' , ' Shoulder season ' )
, ( 93 , ' es ' , ' Temporada media ' )
, ( 94 , ' en ' , ' Offseason ' )
, ( 94 , ' es ' , ' Temporada baja ' )
;
2023-09-27 00:23:09 +00:00
select set_season_range ( 92 , ' [2023-04-06, 2023-04-10] ' ) ;
select set_season_range ( 94 , ' [2023-04-11, 2023-04-27] ' ) ;
select set_season_range ( 93 , ' [2023-04-28, 2023-04-30] ' ) ;
select set_season_range ( 94 , ' [2023-05-01, 2023-06-01] ' ) ;
select set_season_range ( 93 , ' [2023-06-02, 2023-06-03] ' ) ;
select set_season_range ( 94 , ' [2023-06-04, 2023-06-08] ' ) ;
select set_season_range ( 93 , ' [2023-06-09, 2023-06-10] ' ) ;
select set_season_range ( 94 , ' [2023-06-11, 2023-06-15] ' ) ;
select set_season_range ( 93 , ' [2023-06-16, 2023-06-22] ' ) ;
select set_season_range ( 92 , ' [2023-06-23, 2023-06-25] ' ) ;
select set_season_range ( 93 , ' [2023-06-26, 2023-06-30] ' ) ;
select set_season_range ( 92 , ' [2023-07-01, 2023-08-27] ' ) ;
select set_season_range ( 93 , ' [2023-08-28, 2023-09-02] ' ) ;
select set_season_range ( 94 , ' [2023-09-03, 2023-09-07] ' ) ;
select set_season_range ( 93 , ' [2023-09-08, 2023-09-10] ' ) ;
select set_season_range ( 94 , ' [2023-09-11, 2023-09-14] ' ) ;
select set_season_range ( 93 , ' [2023-09-15, 2023-09-16] ' ) ;
select set_season_range ( 94 , ' [2023-09-17, 2023-09-21] ' ) ;
select set_season_range ( 93 , ' [2023-09-22, 2023-09-23] ' ) ;
select set_season_range ( 94 , ' [2023-09-24, 2023-09-28] ' ) ;
select set_season_range ( 93 , ' [2023-09-29, 2023-09-30] ' ) ;
select set_season_range ( 94 , ' [2023-10-01, 2023-10-12] ' ) ;
2023-10-01 19:14:39 +00:00
insert into campsite_type_cost ( campsite_type_id , season_id , cost_per_night , min_nights )
2023-10-06 11:26:01 +00:00
values ( 72 , 92 , 20000 , 1 )
, ( 72 , 93 , 16500 , 1 )
, ( 72 , 94 , 12500 , 1 )
2023-10-01 19:14:39 +00:00
, ( 73 , 92 , 20000 , 2 )
, ( 73 , 93 , 16500 , 2 )
, ( 73 , 94 , 12500 , 2 )
, ( 74 , 92 , 20000 , 2 )
, ( 74 , 93 , 16500 , 2 )
, ( 74 , 94 , 12500 , 2 )
, ( 75 , 92 , 20000 , 2 )
, ( 75 , 93 , 16500 , 2 )
, ( 75 , 94 , 12500 , 2 )
2023-10-06 16:53:44 +00:00
, ( 76 , 92 , 20000 , 2 )
, ( 76 , 93 , 16500 , 2 )
, ( 76 , 94 , 12500 , 2 )
2023-10-01 19:14:39 +00:00
;
2023-10-06 11:26:01 +00:00
alter table campsite_type_option alter column campsite_type_option_id restart with 102 ;
insert into campsite_type_option ( campsite_type_id , name , range )
values ( 72 , ' Adults ' , ' [1, 6] ' )
, ( 72 , ' Nens (de 2 a 10 ' , ' [0, 4] ' )
, ( 72 , ' Tenda petita (màx. 2 ' , ' [0, 3] ' )
, ( 72 , ' Tenda gran ' , ' [0, 3] ' )
, ( 72 , ' Caravana ' , ' [0, 3] ' )
, ( 72 , ' Autocaravana ' , ' [0, 3] ' )
, ( 72 , ' Furgoneta ' , ' [0, 3] ' )
, ( 72 , ' Cotxe ' , ' [0, 3] ' )
, ( 72 , ' Moto ' , ' [0, 3] ' )
, ( 72 , ' Punt electricitat ' , ' [0, 4] ' )
;
insert into campsite_type_option_i18n ( campsite_type_option_id , lang_tag , name )
values ( 102 , ' en ' , ' Adults ' )
, ( 102 , ' es ' , ' Adultos ' )
, ( 103 , ' en ' , ' Children (from 2 to 10 ' )
, ( 103 , ' es ' , ' Niños (de 2 a 10 ' )
, ( 104 , ' en ' , ' Small tent (2 ' )
, ( 104 , ' es ' , ' Tienda pequeña (máx. 2 ' )
, ( 105 , ' en ' , ' Big tent ' )
, ( 105 , ' es ' , ' Tienda grande ' )
, ( 106 , ' en ' , ' Caravan ' )
, ( 106 , ' es ' , ' Caravana ' )
, ( 107 , ' en ' , ' Motorhome ' )
, ( 107 , ' es ' , ' Autocaravana ' )
, ( 108 , ' en ' , ' Van ' )
, ( 108 , ' es ' , ' Furgoneta ' )
, ( 109 , ' en ' , ' Car ' )
, ( 109 , ' es ' , ' Coche ' )
, ( 110 , ' en ' , ' Motorcycle ' )
, ( 110 , ' es ' , ' Moto ' )
, ( 111 , ' en ' , ' Electricity ' )
, ( 111 , ' es ' , ' Puntos de electricidad ' )
;
insert into campsite_type_option_cost ( campsite_type_option_id , season_id , cost_per_night )
values ( 102 , 92 , 795 )
, ( 102 , 93 , 740 )
, ( 102 , 94 , 660 )
, ( 103 , 92 , 640 )
, ( 103 , 93 , 590 )
, ( 103 , 94 , 540 )
, ( 104 , 92 , 620 )
, ( 104 , 93 , 550 )
, ( 104 , 94 , 500 )
, ( 105 , 92 , 800 )
, ( 105 , 93 , 720 )
, ( 105 , 94 , 620 )
, ( 106 , 92 , 900 )
, ( 106 , 93 , 750 )
, ( 106 , 94 , 650 )
, ( 107 , 92 , 1220 )
, ( 107 , 93 , 1100 )
, ( 107 , 94 , 950 )
, ( 108 , 92 , 950 )
, ( 108 , 93 , 850 )
, ( 108 , 94 , 750 )
, ( 109 , 92 , 700 )
, ( 109 , 93 , 630 )
, ( 109 , 94 , 530 )
, ( 110 , 92 , 400 )
, ( 110 , 93 , 360 )
, ( 110 , 94 , 360 )
, ( 111 , 92 , 690 )
, ( 111 , 93 , 610 )
, ( 111 , 94 , 590 )
;
2023-09-26 16:54:20 +00:00
2023-07-27 16:52:01 +00:00
commit ;
