camper/test/campsite.sql

212 lines
6.4 KiB
MySQL
Raw Normal View History

-- Test campsite
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
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
select plan(47);
set search_path to camper, public;
select has_table('campsite');
select has_pk('campsite');
select col_is_unique('campsite', array['company_id', 'label']);
select table_privs_are('campsite', 'guest', array['SELECT']);
select table_privs_are('campsite', 'employee', array['SELECT']);
select table_privs_are('campsite', 'admin', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
select table_privs_are('campsite', 'authenticator', array[]::text[]);
select has_column('campsite', 'campsite_id');
select col_is_pk('campsite', 'campsite_id');
select col_type_is('campsite', 'campsite_id', 'integer');
select col_not_null('campsite', 'campsite_id');
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
select col_hasnt_default('campsite', 'campsite_id');
select has_column('campsite', 'company_id');
select col_is_fk('campsite', 'company_id');
select fk_ok('campsite', 'company_id', 'company', 'company_id');
select col_type_is('campsite', 'company_id', 'integer');
select col_not_null('campsite', 'company_id');
select col_hasnt_default('campsite', 'company_id');
select has_column('campsite', 'campsite_type_id');
select col_is_fk('campsite', 'campsite_type_id');
select fk_ok('campsite', 'campsite_type_id', 'campsite_type', 'campsite_type_id');
select col_type_is('campsite', 'campsite_type_id', 'integer');
select col_not_null('campsite', 'campsite_type_id');
select col_hasnt_default('campsite', 'campsite_type_id');
select has_column('campsite', 'label');
select col_type_is('campsite', 'label', 'text');
select col_not_null('campsite', 'label');
select col_hasnt_default('campsite', 'label');
select has_column('campsite', 'active');
select col_type_is('campsite', 'active', 'boolean');
select col_not_null('campsite', 'active');
select col_has_default('campsite', 'active');
select col_default_is('campsite', 'active', 'true');
set client_min_messages to warning;
truncate campsite cascade;
truncate campsite_type cascade;
Add cover media to campsite types This is the image that is shown at the home page, and maybe other pages in the future. We can not use a static file because this image can be changed by the customer, not us; just like name and description. I decided to keep the actual media content in the database, but to copy this file out to the file system the first time it is accessed. This is because we are going to replicate the database to a public instance that must show exactly the same image, but the customer will update the image from the private instance, behind a firewall. We could also synchronize the folder where they upload the images, the same way we will replicate, but i thought that i would make the whole thing a little more brittle: this way if it can replicate the update of the media, it is impossible to not have its contents; dumping it to a file is to improve subsequent requests to the same media. I use the hex representation of the media’s hash as the URL to the resource, because PostgreSQL’s base64 is not URL save (i.e., it uses RFC2045’s charset that includes the forward slash[0]), and i did not feel necessary write a new function just to slightly reduce the URLs’ length. Before checking if the file exists, i make sure that the given hash is an hex string, like i do for UUID, otherwise any other check is going to fail for sure. I moved out hex.Valid function from UUID to check for valid hex values, but the actual hash check is inside app/media because i doubt it will be used outside that module. [0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
truncate media cascade;
truncate media_content cascade;
truncate company_host cascade;
truncate company_user cascade;
truncate company cascade;
truncate auth."user" cascade;
reset client_min_messages;
insert into auth."user" (user_id, email, name, password, cookie, cookie_expires_at)
values (1, 'demo@tandem.blog', 'Demo', 'test', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e', current_timestamp + interval '1 month')
, (5, 'admin@tandem.blog', 'Demo', 'test', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', current_timestamp + interval '1 month')
;
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, country_code, currency_code, default_lang_tag)
values (2, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', 'ES', 'EUR', 'ca')
, (4, 'Company 4', 'XX234', '', '666-666-666', 'b@b', '', '', '', '', '', 'FR', 'USD', 'ca')
;
insert into company_user (company_id, user_id, role)
values (2, 1, 'admin')
, (4, 5, 'admin')
;
insert into company_host (company_id, host)
values (2, 'co2')
, (4, 'co4')
;
insert into media_content (media_type, bytes)
values ('image/x-xpixmap', 'static char *s[]={"1 1 1 1","a c #ffffff","a"};')
;
insert into media (media_id, company_id, original_filename, content_hash)
values (6, 2, 'cover2.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
, (8, 4, 'cover4.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
Add cover media to campsite types This is the image that is shown at the home page, and maybe other pages in the future. We can not use a static file because this image can be changed by the customer, not us; just like name and description. I decided to keep the actual media content in the database, but to copy this file out to the file system the first time it is accessed. This is because we are going to replicate the database to a public instance that must show exactly the same image, but the customer will update the image from the private instance, behind a firewall. We could also synchronize the folder where they upload the images, the same way we will replicate, but i thought that i would make the whole thing a little more brittle: this way if it can replicate the update of the media, it is impossible to not have its contents; dumping it to a file is to improve subsequent requests to the same media. I use the hex representation of the media’s hash as the URL to the resource, because PostgreSQL’s base64 is not URL save (i.e., it uses RFC2045’s charset that includes the forward slash[0]), and i did not feel necessary write a new function just to slightly reduce the URLs’ length. Before checking if the file exists, i make sure that the given hash is an hex string, like i do for UUID, otherwise any other check is going to fail for sure. I moved out hex.Valid function from UUID to check for valid hex values, but the actual hash check is inside app/media because i doubt it will be used outside that module. [0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
;
insert into campsite_type (campsite_type_id, company_id, media_id, name)
values (22, 2, 6, 'Wooden lodge')
, (44, 4, 8, 'Bungalow')
;
insert into campsite (company_id, campsite_type_id, label)
values (2, 22, 'W1')
, (4, 44, 'B1')
;
prepare campsite_data as
select company_id, label
from campsite
order by company_id, label;
set role guest;
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (4, 'B1')
$$,
'Everyone should be able to list all campsites across all companies'
);
reset role;
select set_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog', 'co2');
select lives_ok(
$$ insert into campsite(company_id, campsite_type_id, label) values (2, 22, 'w2' ) $$,
'Admin from company 2 should be able to insert a new campsite to that company.'
);
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (2, 'w2')
, (4, 'B1')
$$,
'The new row should have been added'
);
select lives_ok(
$$ update campsite set label = 'W2' where company_id = 2 and label = 'w2' $$,
'Admin from company 2 should be able to update campsites of that company.'
);
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (2, 'W2')
, (4, 'B1')
$$,
'The row should have been updated.'
);
select lives_ok(
$$ delete from campsite where company_id = 2 and label = 'W2' $$,
'Admin from company 2 should be able to delete campsites from that company.'
);
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (4, 'B1')
$$,
'The row should have been deleted.'
);
select throws_ok(
$$ insert into campsite (company_id, campsite_type_id, label) values (4, 44, 'W3' ) $$,
'42501', 'new row violates row-level security policy for table "campsite"',
'Admin from company 2 should NOT be able to insert new campsites to company 4.'
);
select lives_ok(
$$ update campsite set label = 'Nope' where company_id = 4 $$,
'Admin from company 2 should NOT be able to update campsite types of company 4, but no error if company_id is not changed.'
);
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (4, 'B1')
$$,
'No row should have been changed.'
);
select throws_ok(
$$ update campsite set company_id = 4 where company_id = 2 $$,
'42501', 'new row violates row-level security policy for table "campsite"',
'Admin from company 2 should NOT be able to move campsites to company 4'
);
select lives_ok(
$$ delete from campsite where company_id = 4 $$,
'Admin from company 2 should NOT be able to delete campsite types from company 4, but not error is thrown'
);
select bag_eq(
'campsite_data',
$$ values (2, 'W1')
, (4, 'B1')
$$,
'No row should have been changed'
);
select throws_ok(
$$ insert into campsite (company_id, campsite_type_id, label) values (2, 22, ' ' ) $$,
'23514', 'new row for relation "campsite" violates check constraint "label_not_empty"',
'Should not be able to insert campsites with a blank label.'
);
reset role;
select *
from finish();
rollback;