Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
|
|
|
-- Test payment_customer
|
|
|
|
set client_min_messages to warning;
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
2024-03-14 21:08:01 +00:00
|
|
|
select plan(49);
|
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
|
|
|
|
|
|
|
set search_path to camper, public;
|
|
|
|
|
|
|
|
select has_table('payment_customer');
|
|
|
|
select has_pk('payment_customer');
|
2024-02-12 17:06:17 +00:00
|
|
|
select table_privs_are('payment_customer', 'guest', array['SELECT', 'INSERT', 'UPDATE']);
|
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
|
|
|
select table_privs_are('payment_customer', 'employee', array['SELECT', 'INSERT', 'UPDATE']);
|
|
|
|
select table_privs_are('payment_customer', 'admin', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
|
|
|
|
select table_privs_are('payment_customer', 'authenticator', array[]::text[]);
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'payment_id');
|
|
|
|
select col_is_pk('payment_customer', 'payment_id');
|
|
|
|
select col_is_fk('payment_customer', 'payment_id');
|
|
|
|
select fk_ok('payment_customer', 'payment_id', 'payment', 'payment_id');
|
|
|
|
select col_type_is('payment_customer', 'payment_id', 'integer');
|
|
|
|
select col_not_null('payment_customer', 'payment_id');
|
|
|
|
select col_hasnt_default('payment_customer', 'payment_id');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'full_name');
|
|
|
|
select col_type_is('payment_customer', 'full_name', 'text');
|
|
|
|
select col_not_null('payment_customer', 'full_name');
|
|
|
|
select col_hasnt_default('payment_customer', 'full_name');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'address');
|
|
|
|
select col_type_is('payment_customer', 'address', 'text');
|
|
|
|
select col_not_null('payment_customer', 'address');
|
|
|
|
select col_hasnt_default('payment_customer', 'address');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'postal_code');
|
|
|
|
select col_type_is('payment_customer', 'postal_code', 'text');
|
|
|
|
select col_not_null('payment_customer', 'postal_code');
|
|
|
|
select col_hasnt_default('payment_customer', 'postal_code');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'city');
|
|
|
|
select col_type_is('payment_customer', 'city', 'text');
|
|
|
|
select col_not_null('payment_customer', 'city');
|
|
|
|
select col_hasnt_default('payment_customer', 'city');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'country_code');
|
|
|
|
select col_is_fk('payment_customer', 'country_code');
|
|
|
|
select fk_ok('payment_customer', 'country_code', 'country', 'country_code');
|
|
|
|
select col_type_is('payment_customer', 'country_code', 'country_code');
|
|
|
|
select col_not_null('payment_customer', 'country_code');
|
|
|
|
select col_hasnt_default('payment_customer', 'country_code');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'email');
|
|
|
|
select col_type_is('payment_customer', 'email', 'email');
|
|
|
|
select col_not_null('payment_customer', 'email');
|
|
|
|
select col_hasnt_default('payment_customer', 'email');
|
|
|
|
|
|
|
|
select has_column('payment_customer', 'phone');
|
|
|
|
select col_type_is('payment_customer', 'phone', 'packed_phone_number');
|
|
|
|
select col_not_null('payment_customer', 'phone');
|
|
|
|
select col_hasnt_default('payment_customer', 'phone');
|
|
|
|
|
2024-02-12 17:06:17 +00:00
|
|
|
select has_column('payment_customer', 'lang_tag');
|
|
|
|
select col_is_fk('payment_customer', 'lang_tag');
|
|
|
|
select fk_ok('payment_customer', 'lang_tag', 'language', 'lang_tag');
|
|
|
|
select col_type_is('payment_customer', 'lang_tag', 'text');
|
|
|
|
select col_not_null('payment_customer', 'lang_tag');
|
|
|
|
select col_hasnt_default('payment_customer', 'lang_tag');
|
|
|
|
|
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
|
|
|
|
|
|
|
select *
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
|