Interval (https://www.threeten.org/threeten-extra/apidocs/org.threeten...) isn't built into java.time, however, it is in the popular threeten-extra library. The docs say "An interval represents the time on the time-line between two Instants." The main difference being that Interval is anchored to the timeline while Duration and Period are not.
If you find your compiles are slow, I found a bug in vscode where builds would compile significantly faster when the status bar and panel are hidden. Compiles that took 20s would take 4s with those panels hidden.
You could write a pl/pgsql function that does that mapping for you. For example, insert into some_table values (intern(str), …) where intern can insert and return the intern_id from your intern_table. For select statements and joins you could use interned(str) that only does select without insert.
Great article. Side note: his normalization example reminded me how I used to design tables using a numeric primary key thinking they were more performant than strings. But then I’d have a meaningless id which required a join to get the unique value I actually wanted. One day I realized I could use the same unique key in both tables and save a join.
I still like to have a unique id field per table. It helps logging and it doesn't care about multi fields "real" key.
However I keep an unique index on the string value and more importantly point integrity constraints to it, mainly for readability. It's way easier to read a table full of meaningful strings rather than full of numerical id or uuids.
You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack
Here is a summary of your argument in your own words:
> So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard.
What others in this thread are arguing is that sharing CC details with anyone is a stupid way of doing payments. It doesn't matter if you're interacting with a PSP or otherwise. You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.
As another person that's worked in payment (specifically aquiring) for 6 years: PCI compliance is not a trivial matter as you seem to believe.
It involves recurring audits of all systems in contact with cc information.
While I've never used stripe, i doubt they'd let you use that API without the certificate, as they wouldn't be able to do the aquiring for illegitimate transactions such as that. They could lose their status as an aquirer if they did that knowingly, and that would make it impossible to process any visa/Mastercard transactions.
You're more likely to encounter a simple scam/phishing site then a legitimate shop that let's cc information onto their servers. And that's honestly the only danger apple pay protects you from.
> You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.
He’s advocating for a more secure one-time way of making a payment.
It would be more secure since it’s one-time and could not be reused even if the merchant didn’t use a pci compliant design
What PCI says is irrelevant. The argument being made is that when you enter your CC number into a website you have no idea if the receiving party is PCI compliant or not. There are ways to design a payment systems that reduces this counter party risk.
> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.
How do you know as a client the merchant doesn’t have a skimmer embedded in their payment page? Or that they don’t post directly to their servers (whether accidentally or not)? Are the PCI police going to catch them? Maybe they want to store cards to process later and don’t know or care about pci.
The problem is using the same details for every transaction in a loosely authorized way.
In a perfect world the merchant won’t have access to the card details (like with one-time payments) and everything would go thru a provider with a preauthorized payment. But we don’t live in that world right now.
> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.
No. In best case, you’re giving your payment details to a PSP. A couple years ago NewEgg had a javascript skimmer on their checkout page that harvested all their customers payment details for months. Obviously anyone with access and intent could do the same for any payment page.
It appears to be a bot they use for automated responses. The issue was closed and reopened multiple times before realizing it wasn't a duplicate bug so there's a couple automated responses from the triage bot.
The output is apples and oranges tho. Since I was downvoted by someone I'll added a simple example to show the difference between the two interfaces. I shouldn't have assumed anyone here was familiar with the respective representations.
Sample data:
CREATE TABLE users (user_id serial, name text);
CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id;
INSERT INTO users VALUES (1, 'Bob');
INSERT INTO users VALUES (2, 'Sally');
SQLITE3 OUTPUT
sqlite> .schema
CREATE TABLE users (user_id serial, name text);
CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id
/* user_comment_view(user_id,comment) */;
sqlite> .schema users
CREATE TABLE users (user_id serial, name text);
sqlite> select * from users;
1|Bob
2|Sally
POSTGRESQL OUTPUT
test=# \d
List of relations
Schema | Name | Type | Owner
--------+-------------------------+----------+----------
public | comments | table | postgres
public | comments_comment_id_seq | sequence | postgres
public | user_comment_view | view | postgres
public | users | table | postgres
public | users_user_id_seq | sequence | postgres
(5 rows)
test=# \d users
Table "public.users"
Column | Type | Collation | Nullable | Default
---------+---------+-----------+----------+----------------------------------------
user_id | integer | | not null | nextval('users_user_id_seq'::regclass)
name | text | | |
test=# select * from users;
user_id | name
---------+-------
1 | Bob
2 | Sally
(2 rows)
Postgres also supports adding + to commands to get additional extended information, eg, \d+. You can also filter by tables (\dt), filter by views (\dv), filter by functions (\df), etc. It's allows much more natural enumeration of the DB which I wish sqlite had as well.
