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

167 lines
5.7 KiB
MySQL
Raw Normal View History

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
-- Deploy camper:draft_payment to pg
-- requires: roles
-- requires: schema_camper
-- requires: season_calendar
-- requires: season
-- requires: campsite_type
-- requires: campsite_type_pet_cost
-- requires: campsite_type_cost
-- requires: campsite_type_option_cost
-- requires: campsite_type_option
-- requires: payment
-- requires: payment_option
begin;
set search_path to camper, public;
create type option_units as (option_id integer, units integer);
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
create or replace function draft_payment(payment_slug uuid, arrival_date date, departure_date date, campsite_type_slug uuid, num_adults integer, num_teenagers integer, num_children integer, num_dogs integer, zone_preferences text, options option_units[]) returns payment as
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
$$
declare
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
p payment;
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
begin
Create new drafts if trying to modify an already pending payment This can happen when the customer reaches the payment page, but then returns back to the booking form via the back button: the browser remembers the URI with the cart slug, trying to make it ready, and then it fails because it is already pending. I did not like the idea of modifying a payment that is already not a draft, because it seems to me that can lead to errors if we receive Redsys notifications of payments that are being changed back to draft. In fact, i believe that draft payments maybe should go to a different relation altogether, so that i can prevent UPDATE on payment by guests, but maybe i am going overboard now.
2024-02-13 19:16:12 +00:00
if exists(select 1 from payment where slug = payment_slug and payment_status <> 'draft') then
payment_slug = null;
end if;
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
insert into payment (
slug
, company_id
, campsite_type_id
, arrival_date
, departure_date
, subtotal_nights
, number_adults
, subtotal_adults
, number_teenagers
, subtotal_teenagers
, number_children
, subtotal_children
, number_dogs
, subtotal_dogs
, subtotal_tourist_tax
, total
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
, down_payment_percent
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
, zone_preferences
)
select coalesce(payment_slug, gen_random_uuid())
, company_id
, campsite_type_id
, arrival_date
, departure_date
, sum(cost.cost_per_night * ceiling((num_adults::numeric + num_teenagers::numeric + num_children::numeric) / max_campers::numeric)::integer)::integer
, num_adults
, sum(cost_per_adult * num_adults)::integer
, num_teenagers
, sum(cost_per_teenager * num_teenagers)::integer
, num_children
, sum(cost_per_child * num_children)::integer
, num_dogs
, sum(case when num_dogs > 0 then coalesce(pet.cost_per_night, 0) else 0 end)::integer
, sum(tourist_tax * num_adults)::integer
, 0
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
, case when arrival_date - current_date >= 7 then 0.3 else 1.0 end
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
, coalesce(zone_preferences, '')
from generate_series(arrival_date, departure_date - 1, interval '1 day') as date(day)
left join season_calendar on season_range @> date.day::date
left join season using (season_id)
left join campsite_type using (company_id)
left join campsite_type_pet_cost as pet using (campsite_type_id)
left join campsite_type_cost as cost using (campsite_type_id, season_id)
left join company using (company_id)
where campsite_type.slug = campsite_type_slug
group by company_id
, campsite_type_id
on conflict (slug) do update
set company_id = excluded.company_id
, campsite_type_id = excluded.campsite_type_id
, arrival_date = excluded.arrival_date
, departure_date = excluded.departure_date
, subtotal_nights = excluded.subtotal_nights
, number_adults = excluded.number_adults
, subtotal_adults = excluded.subtotal_adults
, number_teenagers = excluded.number_teenagers
, subtotal_teenagers = excluded.subtotal_teenagers
, number_children = excluded.number_children
, subtotal_children = excluded.subtotal_children
, number_dogs = excluded.number_dogs
, subtotal_dogs = excluded.subtotal_dogs
, subtotal_tourist_tax = excluded.subtotal_tourist_tax
, total = excluded.total
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
, down_payment_percent = excluded.down_payment_percent
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
, zone_preferences = excluded.zone_preferences
, updated_at = current_timestamp
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
returning *
into p
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
;
if array_length(coalesce(options, array[]::option_units[]), 1) > 0 then
delete
from payment_option
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
where payment_id = p.payment_id
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
and campsite_type_option_id not in (
select campsite_type_option_id
from unnest(options) as option(campsite_type_option_id, units)
);
insert into payment_option (
payment_id
, campsite_type_option_id
, units
, subtotal
)
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
select p.payment_id
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
, campsite_type_option_id
, units
, case when per_night then sum(cost * units)::integer else max(cost * units)::integer end
from generate_series(arrival_date, departure_date - 1, interval '1 day') as date(day)
join season_calendar on season_range @> date.day::date
join campsite_type_option_cost using (season_id)
join campsite_type_option using (campsite_type_option_id)
join unnest(options) as option(campsite_type_option_id, units) using (campsite_type_option_id)
group by campsite_type_option_id
, units
, per_night
on conflict (payment_id, campsite_type_option_id) do update
set units = excluded.units
, subtotal = excluded.subtotal
;
with option as (
select sum(subtotal)::integer as subtotal
from payment_option
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
where payment_id = p.payment_id
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
)
update payment
set total = subtotal_nights + subtotal_adults + subtotal_teenagers + subtotal_children + subtotal_dogs + subtotal_tourist_tax + coalesce(option.subtotal, 0)
from option
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
where payment_id = p.payment_id
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
returning total into p.total
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
;
else
delete
from payment_option
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
where payment_id = p.payment_id;
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
update payment
set total = subtotal_nights + subtotal_adults + subtotal_teenagers + subtotal_children + subtotal_dogs + subtotal_tourist_tax
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
where payment_id = p.payment_id
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
returning total into p.total
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
;
end if;
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
return p;
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
end;
$$
language plpgsql
;
revoke execute on function draft_payment(uuid, date, date, uuid, integer, integer, integer, integer, text, option_units[]) from public;
grant execute on function draft_payment(uuid, date, date, uuid, integer, integer, integer, integer, text, option_units[]) to guest;
grant execute on function draft_payment(uuid, date, date, uuid, integer, integer, integer, integer, text, option_units[]) to employee;
grant execute on function draft_payment(uuid, date, date, uuid, integer, integer, integer, integer, text, option_units[]) to admin;
commit;