tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/test/remove_home_carousel_slide.sql

88 lines
3.2 KiB
MySQL
Raw Normal View History

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
-- Test remove_home_carousel_slide
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
select plan(12);
set search_path to camper, public;
select has_function('camper', 'remove_home_carousel_slide', array['integer']);
select function_lang_is('camper', 'remove_home_carousel_slide', array['integer'], 'sql');
select function_returns('camper', 'remove_home_carousel_slide', array['integer'], 'void');
select isnt_definer('camper', 'remove_home_carousel_slide', array['integer']);
select volatility_is('camper', 'remove_home_carousel_slide', array['integer'], 'volatile');
select function_privs_are('camper', 'remove_home_carousel_slide', array['integer'], 'guest', array[]::text[]);
select function_privs_are('camper', 'remove_home_carousel_slide', array['integer'], 'employee', array[]::text[]);
select function_privs_are('camper', 'remove_home_carousel_slide', array['integer'], 'admin', array['EXECUTE']);
select function_privs_are('camper', 'remove_home_carousel_slide', array['integer'], 'authenticator', array[]::text[]);
set client_min_messages to warning;
truncate home_carousel_i18n cascade;
truncate home_carousel cascade;
truncate media cascade;
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
truncate media_content cascade;
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
truncate company cascade;
reset client_min_messages;
Add the number of maximum nights that tourist tax applies This is required by law. I do not know why i have this value and the tax amount in the database, but the payment percent and the number of days are hardcoded. I guess i am such an inconsistent mess.
2024-02-27 18:45:47 +00:00
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, rtc_number, tourist_tax, tourist_tax_max_days, country_code, currency_code, default_lang_tag)
values (1, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 60, 7, 'ES', 'EUR', 'ca')
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
;
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
insert into media_content (media_type, bytes)
values ('text/plain', 'hello, world!')
, ('image/svg+xml', '<svg xmlns="http://www.w3.org/2000/svg" width="1" height="1"/>')
, ('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 (5, 1, 'text.txt', sha256('hello, world!'))
, (6, 1, 'image.svg', sha256('<svg xmlns="http://www.w3.org/2000/svg" width="1" height="1"/>'))
, (7, 1, 'cover4.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
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 (5, 'Source caption')
, (6, 'Another caption')
, (7, 'N/A')
;
insert into home_carousel_i18n (media_id, lang_tag, caption)
values (5, 'en', 'Target caption')
, (5, 'es', 'Target caption (spanish)')
, (6, 'en', 'Target caption')
, (6, 'es', 'Target caption (spanish)')
, (7, 'en', 'Target caption')
, (7, 'es', 'Target caption (spanish)')
;
select lives_ok(
$$ select remove_home_carousel_slide(6) $$,
'Should be able to delete a slide'
);
select bag_eq(
$$ select media_id, caption from home_carousel $$,
$$ values (5, 'Source caption')
, (7, 'N/A')
$$,
'Should have removed the slide'
);
select bag_eq(
$$ select media_id, lang_tag, caption from home_carousel_i18n $$,
$$ values (5, 'en', 'Target caption')
, (5, 'es', 'Target caption (spanish)')
, (7, 'en', 'Target caption')
, (7, 'es', 'Target caption (spanish)')
$$,
'Should have removed the slide’s translations'
);
select *
from finish();
rollback;