camper/demo/demo.sql

509 lines
25 KiB
MySQL
Raw Normal View History

-- m4_changequote(`[[', `]]')
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;
insert into auth."user" (email, name, password, lang_tag)
values ('demo@camper', 'Demo User', 'demo', 'ca')
, ('admin@camper', 'Demo Admin', 'admin', 'ca')
;
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;
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', '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 dacord amb el RGPD i la LOPDGDD, i les tracta per a mantenir una relació mercantil/comercial amb vostè. Les conservarà mentre es mantingui aquesta relació i no es comunicaran a tercers. Pot exercir els drets daccés, rectificació, portabilitat, supressió, limitació i oposició a El pont de Llierca, S.L., amb domicili Ctra. de Sadernes, Km 2, 17855 Montagut i Oix o enviant un correu electrònic a info@campingmontagut.com. Per a qualsevol reclamació pot acudir a agpd.es. Per a més informació pot consultar la nostra política de privacitat a campingmontagut.com.');
insert into company_host (company_id, host)
values (52, 'localhost:8080')
, (52, 'camper.tandem.ws')
;
insert into company_geography (company_id, geog)
values (52, 'SRID=4326;POINT(2.598825853208973 42.24256146290889)')
;
insert into company_user (company_id, user_id, role)
values (52, 42, 'employee')
, (52, 43, 'admin')
;
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;
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'));
select add_media(52, 'bungalows_premium.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_premium.avif]])', 'base64'));
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'));
select add_media(52, 'safari_tents_carousel1.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel1.avif]])', 'base64'));
select add_media(52, 'safari_tents_carousel2.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel2.avif]])', 'base64'));
select add_media(52, 'safari_tents_carousel3.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel3.avif]])', 'base64'));
select add_media(52, 'safari_tents_carousel4.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel4.avif]])', 'base64'));
select add_media(52, 'safari_tents_carousel5.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel5.avif]])', 'base64'));
select add_media(52, 'safari_tents_carousel6.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/safari_tents_carousel6.avif]])', 'base64'));
select add_media(52, 'bungalows_carousel2.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_carousel2.avif]])', 'base64'));
select add_media(52, 'bungalows_carousel3.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_carousel3.avif]])', 'base64'));
select add_media(52, 'bungalows_carousel4.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_carousel4.avif]])', 'base64'));
select add_media(52, 'bungalows_carousel5.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_carousel5.avif]])', 'base64'));
select add_media(52, 'bungalows_carousel6.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/bungalows_carousel6.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel0.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel0.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel1.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel1.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel2.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel2.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel3.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel3.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel4.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel4.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel5.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel5.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel6.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel6.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel7.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel7.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel8.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel8.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carousel9.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carousel9.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carouselA.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carouselA.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carouselB.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carouselB.avif]])', 'base64'));
select add_media(52, 'wooden_lodges_carouselC.avif', 'image/avif', decode('m4_esyscmd([[base64 -w0 demo/wooden_lodges_carouselC.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)
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)
values (67, 'en', 'Santa Margarida volcano')
, (67, 'es', 'Volcán de Santa Margarida')
, (68, 'en', 'Sadernes dark gorge')
, (68, 'es', 'Piletón oscuro Sadernes')
;
insert into services_carousel (media_id, caption)
values (76, 'La Garrotxa')
, (77, 'Tenda')
, (78, 'Parceŀles')
, (79, 'Hamaca')
, (63, 'Safari Tents')
;
insert into services_carousel_i18n (media_id, lang_tag, caption)
values (77, 'en', 'Tent')
, (77, 'es', 'Tenda')
, (78, 'en', 'Plots')
, (78, 'es', 'Parcelas')
, (79, 'en', 'Hammock')
, (79, 'es', 'Amaca')
, (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;
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);
select add_campsite_type(52, 65, 'Bungalous prèmium', '', 5, false);
select add_campsite_type(52, 66, 'Cabanes de fusta', '', 5, false);
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', 'Bungalows premium', '')
, (75, 'es', 'Bungalós prémium', '')
, (76, 'en', 'Wooden Lodges', '')
, (76, 'es', 'Cabañas de madera', '')
;
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;
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');
select add_campsite(73, '78');
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');
select add_campsite(76, '84');
select add_campsite(76, '85');
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;
insert into service (company_id, icon_name, name, description)
values (52, 'information', 'Informació', '<p>A la recepció linformarem del que pot fer des del càmping mateix o pels voltants.</p>')
, (52, 'wifi', 'WiFi', '<p>Un 80 % de làrea del càmping disposa daccés WiFi lliure.</p>')
, (52, 'restaurant', 'Bar & Tapes', '<p>Oberts:</p><ul><li>De l01/07 al 28/08: cada dia</li><li>Dabril a setembre: caps de setmana i ponts</li></ul>')
, (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 lentrada del càmping.</p>')
, (52, 'castle', 'Zona de jocs', '<p>Una zona central pels més menuts.</p>')
, (52, 'ball', 'Camp desport', '<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 % of the campsite area has free WiFi access.</p>')
, (83, 'es', 'WiFi', '<p>Un 80 % del área del camping dispone de acceso WiFi libre.</p>')
, (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 childrens pool.</p><p><em>(Salt water swimming pools.)</em></p>')
, (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 campsites laundry facilities.</p>')
, (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');
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')
;
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)
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)
, (76, 92, 20000, 2)
, (76, 93, 16500, 2)
, (76, 94, 12500, 2)
2023-10-01 19:14:39 +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 anys)', '[0, 4]')
, (72, 'Tenda petita (màx. 2 pers.)', '[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 years)')
, (103, 'es', 'Niños (de 2 a 10 años)')
, (104, 'en', 'Small tent (2 pax max.)')
, (104, 'es', 'Tienda pequeña (máx. 2 pers.)')
, (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
insert into campsite_type_carousel (campsite_type_id, media_id, caption)
values (72, 77, 'Llegenda')
, (72, 78, 'Llegenda')
, (72, 79, 'Llegenda')
, (73, 63, 'Llegenda')
, (73, 80, 'Llegenda')
, (73, 81, 'Llegenda')
, (73, 82, 'Llegenda')
, (73, 83, 'Llegenda')
, (73, 84, 'Llegenda')
, (73, 85, 'Llegenda')
, (74, 64, 'Llegenda')
, (74, 65, 'Llegenda')
, (74, 86, 'Llegenda')
, (74, 87, 'Llegenda')
, (74, 88, 'Llegenda')
, (74, 89, 'Llegenda')
, (74, 90, 'Llegenda')
, (75, 65, 'Llegenda')
, (75, 64, 'Llegenda')
, (75, 88, 'Llegenda')
, (75, 86, 'Llegenda')
, (75, 87, 'Llegenda')
, (76, 91, 'Llegenda')
, (76, 92, 'Llegenda')
, (76, 93, 'Llegenda')
, (76, 94, 'Llegenda')
, (76, 95, 'Llegenda')
, (76, 96, 'Llegenda')
, (76, 97, 'Llegenda')
, (76, 98, 'Llegenda')
, (76, 99, 'Llegenda')
, (76, 100, 'Llegenda')
, (76, 101, 'Llegenda')
, (76, 102, 'Llegenda')
, (76, 103, 'Llegenda')
;
insert into campsite_type_carousel_i18n (campsite_type_id, media_id, lang_tag, caption)
values (72, 77, 'en', 'Legend')
, (72, 77, 'es', 'Leyenda')
, (72, 78, 'en', 'Legend')
, (72, 78, 'es', 'Leyenda')
, (72, 79, 'en', 'Legend')
, (72, 79, 'es', 'Leyenda')
, (73, 63, 'en', 'Legend')
, (73, 63, 'es', 'Leyenda')
, (73, 80, 'en', 'Legend')
, (73, 80, 'es', 'Leyenda')
, (73, 81, 'en', 'Legend')
, (73, 81, 'es', 'Leyenda')
, (73, 82, 'en', 'Legend')
, (73, 82, 'es', 'Leyenda')
, (73, 83, 'en', 'Legend')
, (73, 83, 'es', 'Leyenda')
, (73, 84, 'en', 'Legend')
, (73, 84, 'es', 'Leyenda')
, (73, 85, 'en', 'Legend')
, (73, 85, 'es', 'Leyenda')
, (74, 64, 'en', 'Legend')
, (74, 64, 'es', 'Leyenda')
, (74, 65, 'en', 'Legend')
, (74, 65, 'es', 'Leyenda')
, (74, 86, 'en', 'Legend')
, (74, 86, 'es', 'Leyenda')
, (74, 87, 'en', 'Legend')
, (74, 87, 'es', 'Leyenda')
, (74, 88, 'en', 'Legend')
, (74, 88, 'es', 'Leyenda')
, (74, 89, 'en', 'Legend')
, (74, 89, 'es', 'Leyenda')
, (74, 90, 'en', 'Legend')
, (74, 90, 'es', 'Leyenda')
, (75, 65, 'en', 'Legend')
, (75, 65, 'es', 'Leyenda')
, (75, 64, 'en', 'Legend')
, (75, 64, 'es', 'Leyenda')
, (75, 88, 'en', 'Legend')
, (75, 88, 'es', 'Leyenda')
, (75, 86, 'en', 'Legend')
, (75, 86, 'es', 'Leyenda')
, (75, 87, 'en', 'Legend')
, (75, 87, 'es', 'Leyenda')
, (76, 91, 'en', 'Legend')
, (76, 91, 'es', 'Leyenda')
, (76, 92, 'en', 'Legend')
, (76, 92, 'es', 'Leyenda')
, (76, 93, 'en', 'Legend')
, (76, 93, 'es', 'Leyenda')
, (76, 94, 'en', 'Legend')
, (76, 94, 'es', 'Leyenda')
, (76, 95, 'en', 'Legend')
, (76, 95, 'es', 'Leyenda')
, (76, 96, 'en', 'Legend')
, (76, 96, 'es', 'Leyenda')
, (76, 97, 'en', 'Legend')
, (76, 97, 'es', 'Leyenda')
, (76, 98, 'en', 'Legend')
, (76, 98, 'es', 'Leyenda')
, (76, 99, 'en', 'Legend')
, (76, 99, 'es', 'Leyenda')
, (76, 100, 'en', 'Legend')
, (76, 100, 'es', 'Leyenda')
, (76, 101, 'en', 'Legend')
, (76, 101, 'es', 'Leyenda')
, (76, 102, 'en', 'Legend')
, (76, 102, 'es', 'Leyenda')
, (76, 103, 'en', 'Legend')
, (76, 103, 'es', 'Leyenda')
;
commit;