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 ;
alter sequence user_user_id_seq restart with 42 ;
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 auth . " user " ( email , name , password )
values ( ' demo@camper ' , ' Demo User ' , ' demo ' )
, ( ' admin@camper ' , ' Demo Admin ' , ' admin ' )
2023-07-27 16:52:01 +00:00
;
2023-07-29 02:25:56 +00:00
alter sequence company_company_id_seq 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 )
values ( ' 09184122-b276-4be2-9553-e4bbcbafe40d ' , ' Càmping les mines, S.L.U. ' , ' ESB17616756 ' , ' Pescamines ' , parse_packed_phone_number ( ' 972 50 60 70 ' , ' ES ' ) , ' info@lesmines.cat ' , ' https://lesmines.cat/ ' , ' C/ de l’ ' , ' Castelló d’ ' , ' Girona ' , ' 17486 ' , ' ES ' , ' EUR ' , ' ca ' , ' Càmping les mines, S.L.U. é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 ' )
;
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
;
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
alter sequence media_media_id_seq restart with 62 ;
insert into media ( company_id , original_filename , media_type , content )
values ( 52 , ' plots.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/plots.avif]]) ' , ' base64 ' ) )
, ( 52 , ' safari_tents.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/safari_tents.avif]]) ' , ' base64 ' ) )
, ( 52 , ' bungalows.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/bungalows.avif]]) ' , ' base64 ' ) )
, ( 52 , ' wooden_lodges.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/wooden_lodges.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
, ( 52 , ' home_carousel0.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel0.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel1.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel1.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel2.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel2.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel3.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel3.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel4.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel4.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel5.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel5.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel6.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel6.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel7.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel7.jpg]]) ' , ' base64 ' ) )
, ( 52 , ' home_carousel8.jpg ' , ' image/jpeg ' , decode ( ' m4_esyscmd([[base64 -w0 demo/home_carousel8.jpg]]) ' , ' base64 ' ) )
;
insert into home_carousel ( media_id , caption )
values ( 66 , ' Volcà de Santa Margarida ' )
, ( 67 , ' Gorga fosca Sadernes ' )
, ( 68 , ' Castellfollit de la Roca ' )
, ( 69 , ' Besalú ' )
, ( 70 , ' Santa Pau ' )
, ( 71 , ' Banyoles ' )
, ( 72 , ' Girona ' )
, ( 73 , ' Costa Brava ' )
, ( 74 , ' Barcelona ' )
;
insert into home_carousel_i18n ( media_id , lang_tag , caption )
values ( 66 , ' en ' , ' Santa Margarida volcano ' )
, ( 66 , ' es ' , ' Volcán de Santa Margarida ' )
, ( 67 , ' en ' , ' Sadernes dark gorge ' )
, ( 67 , ' 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
;
alter sequence campsite_type_campsite_type_id_seq restart with 72 ;
insert into campsite_type ( company_id , name , media_id , description )
values ( 52 , ' Parceŀles ' , 62 , ' ' )
, ( 52 , ' Safari Tents ' , 63 , ' ' )
2023-09-12 18:20:23 +00:00
, ( 52 , ' Bungalous ' , 64 , ' ' )
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
, ( 52 , ' Cabanes de fusta ' , 65 , ' ' )
;
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 ' , ' ' )
, ( 75 , ' en ' , ' Wooden Lodges ' , ' ' )
, ( 75 , ' es ' , ' Cabañas de madera ' , ' ' )
;
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
2023-07-27 16:52:01 +00:00
commit ;
