Hacker News Reader

Comment by malikolivier | Hacker News Reader

I moved twice since I originally backed it.

Each time, I was able to update the shipping address on my account: https://shop.puri.sm/my-account/edit-address/

For good measure, I just checked and the currently set shipping address in indeed my current and latest address!

More importantly, it was confirmed on the forum that changing your address in your account will NOT update the Librem 5 shipping address.

Purism is emailing each person to get their updated address, modem preferences and give them a chance to purchase additional accessories, before they ship the phones.

So you'll need to be on the lookout for that pre-shipping email to update your address correctly.

I smell a NoSQL database keeping those addresses.

You don't generally update the shipping address for pending orders when a user changes their address. Of course, when an order is delayed by years the rules might change a little and asking the users whether the orders should be updated too will be useful.

It's precisely the "this is the way it's done" approach you mention, which means they now have to pay a human to do the work their web stack ought to do!

They can pay a human to update their web stack instead? Seems more efficient.

Precisely! So picture some, however oversimplified, code which searches a customer's orders, determines which is a phone product id, remembering they sell other stuff which we would not want to update in flight order details on, then updates the embedded customer address on the order.

I would like to hear some original thoughts on why this is so difficult that a human is doing this work instead.

Obviously maintaining a different behaviour for a class of product ids is painful and not beautiful code to look at, but it is the real world.

It's not "this is the way it's done", it's "this is how it should be done". Shipping information is much like the rest of the order information, you want a de-normalized price on the order and each line item in the database, not a normalized cost based on the price of things now. You want a denormalised record of which card was charged, not a normalized record showing what their current card is, etc.

I get little bursts of joy about 3-5 times per week when I see some low-effort misinformed comments, followed by that brain urge to set the record straight, followed immediately by discovering the fact that someone with specific domain knowledge, experience, or both has taken the time to write a thoughtful reply like this one, educating everyone who reads it.

This isn’t an isolated case: as I mentioned, I see it at least a few times per week and I imagine this happens at least a dozen times a day here in some thread or other.

Thanks for being awesome flukus. I love HN.

I loved to see this from students talking to professors while studying CS. I think it has to do with the ego boost you get from acquiring the "power" to code rising above mere mortals.

Unless you are a psychopath, you will realize later in life, that there are actually other smart people, who might know something you do not. Even though it often times feels like you are surrounded by idiots.

While I disagree with the positions put forward by lolc and flukus, that Librem 5 should have the customer address modelled analogously to some 'fast moving goods' e-commerce implementation, I appreciate their comments for being constructive and actually adding something to the discussion.

Storytime: As part of moving to another city, I put a chest freezer on an auction platform, specifying that it must be picked up from my location. While that auction ran its course, I minded offline and online services and updated my address to the new address so that letters would already arrive at my new location. Now came the day where somebody would come pick up the freezer. Which address do you think did the auction platform give them where it could be picked up?

Well the Librem 5 is not another 'widget in a warehouse'. It was always going to be a long wait to delivery, due to the enormity of the undertaking. This was not a surprise to anyone. Addresses will need to be updated after order in this case! Every implementation is different.

Consider the scenario where right from the start they accepted the shortcomings of their system for this use-case.

Hate to break it, but for a lot of real world applications it is preferable to duplicate stuff like addresses when shipping orders, generating invoices etc, everything that resembles paper.

For easier archiving and proper retrieval of history.

It's WP/WooCommerce so likely MySQL...

Ah good insight, thanks.

Yeah IIRC Woocommerce creates a new "Order" record, copying the shipping address from your account if you have one saved or using the one manually inputted at checkout. It makes sense that the account email doesn't update shipping email, generally companies will try to keep payment/purchase/shipping stuff in a "frozen" state or at least something where edits or logged, so in the case of issues, they can see what the user entered initially.

Same practice goes with credit cards, a charge confirmation (like something that would be generated after a stripe charge.succeeded webhook) stored in DB wouldn't be retroactively updated to new last-4-digits if the user switches the card saved in their account.

Reply on news.ycombinator.com