And preferably you use the postgres specific "unnest(array1, array2, ...)" function which turns array parameters passed into the query into a temporary table that you can query.
UPDATE example
SET position = CAST(temp.position AS INTEGER)
FROM unnest(:ids, :positions) AS temp (id, position)
WHERE example.id = CAST(temp.id AS INTEGER);
OK, so SQL extensions, so just the usual reasons to do bulk changes. I thought they might have mentioned it here because there was something unique to say about it in the context of this problem.
Yeah, that section doesn't seem to be making much sense. I don't think there are actually any real examples of "graph sharding" in the wild. The graph databases that are available, like Neo4j, don't usually natively provide horizontal partitioning. (Of course -- the problem of finding the minimum k-cut of a graph is itself NP-complete. Doing this incrementally with a dynamic graph is even harder.)
The one solution that was mentioned, Facebook's TAO, isn't actually really a database; it's a cache, which means that it doesn't really have to deal with sharding in the way that persistent stores do. And it doesn't really shard at all; it basically stores a complete copy of the world's social graph in every region, which it can just populate from that region's MySQL replicas. (It's amazing the things you can do when you can be eventually consistent.)
(From what I recall, the main social network's MySQL also isn't really sharded by graph in any fancy way; it's basically "just" hash-sharded by entity ID.)
dgraph does try to provide horizontal scaling out of the box. The sharding is done by predicate - cf https://docs.dgraph.io/deploy/#multiple-instances for a documentation link ; I am not sure how it behaves for very frequent predicates though
All of these response posts seem to miss one big piece that made no sense to me. Uber goes really in-depth around the higher cost of updates in postgres, but then Uber describes Schemaless as an immutable append only data store. They created a custom database with no updates, but one of their primary reasons for changing from postgres to mysql was because of the high cost of updates?
From what I can tell Schemaless has updates but represents them as inserts. When you want to change something (e.g. change the billing status of a trip), it writes a new billing status for the trip and consumers will always ask for the latest billing status for the trip, which is the most recent and up-to-date one.
Take this with a grain of salt, I just read the Schemaless articles yesterday.
That is how I understood it too. Updating your data with a call to insert won't run into the same problems as updating your data with a call to update. Their immutability implementation seems like it would behave nearly the same under both databases.
Most of the conversation on the topic misses that Uber's actions are totally irrelevant to 99.9% of us. Uber has unlimited resources and unique problems. Sure, it's interesting but ultimately almost entirely meaningless.
Schemaless is primarily a sharding scheme for MySQL. It's possible that using Postgres in an append-only manner would have created too many records to handle without an analogous sharding scheme.
From the little I can see from their blog posts, Schemaless seems to be both a sharding layer and an immutability layer that can sit on top of postgres or mysql. However, discussing the costs of mutable data when you have created an immutable data storage layer doesn't make much sense.
I interviewed/phone screened Xah Lee about 2 years ago.
I'd never heard of him, so I skimmed over his resume and checked out his site an hour or two before the call. I remember when I was looking at his site I was seeing various articles around math and programming, and then articles about things like "2 girls 1 cup". The breadth of articles completely threw me off. He seemed to have this unfocused interest in EVERYTHING. After looking over everything I could I had no idea how we'd be able to use him, but I was really interested in talking with him.
I went into the call expecting a lot of tangents about various topics he was passionate about and thinking I'd constantly have to refocus the conversation. Instead the conversation was pretty boring and not really going anywhere. He had breadth, but the depth was not there. At least not for the things I brought up. I couldn't understand how someone who seemed to be interested in everything could have no real interest in anything.
For the last couple of minutes we talked about his site, and how he maintains/updates it. He finally seemed to light up, and we hit on something he was really interested in talking about. The basics of the site looked like it was just a couple of scripts, a lot of static text files and some emacs. The setup might have been impressive in the mid-to-early 90's, but it wasn't relevant to anything we would have wanted/needed.
The call lasted maybe 20 minutes, and then we wrapped it up. Every topic, other than talking about his site, was a dead-end. My internal feedback at the end was: "No! Maybe... if we were trying to hire encyclopedia writers".
I think his main problem with interviews is that his real-life personality doesn't even come close to his online personality. If I would have gone in expecting the standard slightly-awkward developer interview, things might have gone better. I still would have said no, but it would have been a weaker no.
Not so internal anymore! Don't get me wrong, I read your comment with interest, but then was struck with how we are talking about him as if he _was_ dead. Apparently he likes his life to be public but actual job interviews somehow strike me as private.
You're right. I was thinking about it for a while and have seen his name show up other times where I've thought about commenting and haven't. Normally I wouldn't say anything, and it would have stayed personal and private. I hovered over the submit buttton for a few minutes and then even after I submitted I was hovering over the delete link for a few minutes.
I wanted to give some perspective on what "not interviewing well" means in this case. It seemed as if a lot of comments were assuming age discrimination and issues with mental illness among other things. I wouldn't doubt that is the case sometimes, but from my experience that wasn't the case. There were other issues. I'm sure most people who interview him run into the same issues.
I think his biggest interviewing problem is that he can't live up to the expectations others will expect from a one-man encyclopedia.
This is a total gray area at this point. I had no idea who this guy was before this post and now I know more about him than some of my close friends and all by his own admission. I'm glad Beanis added his viewpoint, it doesn't give too much away but provides a more nuanced understanding of what the issues are for this guy who is obviously technically very capable.
Some people take a while to warm up to a conversation. Some people are cagey. Some just don't know how to dance the phone interview minuet.
The conversation didn't follow the script in the interviewer's head. Maybe that's because he wasn't interested in the topics at the start of the interview, maybe it's because the interviewee wasn't comfortable until the interviewer expressed an interest at a less impersonal level.
Think about it this way, what really interested the interviewer was the website, and until that came up the topics were from a checklist. Many people can tell the difference between going through the motions and seeking information.
The icebreaker was the website and then the conversation ended. To keep things moving, it's often better to put the icebreaker in front of the convoy.
I used to be terrible at interviewing. I know when I see other people going through similar problems, and make every attempt I can to work around them. There is only so much you can do though, and you have to accept that you will miss out out on some good candidates.
The phone screens I performed were just a quick first round check to see if a candidate would be a valuable employee for us. They weren't supposed to be super in-depth or time consuming for either party. The whole thing is basically one big ice breaker. Hoping that I can hit on some topic that will cause a candidate to expose some skill, knowledge or enthusiasm that would move the company forward. There was very little structure. It was all about finding skill overlap, and then trying to decide if they would pass an in-person round of interviewing. If I hit on an ice-breaker at the end of a conversation, it means I had already exhausted all of the others.
Oh yeah, I know it's business and I'm not suggesting someone missed out on an ideal candidate. I was really just thinking it through and thinking about how people at the fringe see the world and how hard it is to cross that barrier.
Part of that is mediated by my experience when I first discovered his site. I was learning about Emacs when I found it, I'm pretty sure. Anyway, there was something I thought was pretty interesting - might or might not have been Emacs related - so I submitted it to HN. Showed up dead, immediately. Apparently his site was banned. It no longer is, of course.
But that's the way his relationship with the tech world was structured - banned by HN. Now maybe he had been spamming submissions or trolling, but it's possible his site was just blocked because it was Xah Lee: I mean there are people in this thread who are still judging him based on his behavior a decade or two ago.
A person who has spent a lifetime as an outsider is likely to have a different set of defense mechanisms - a different set of survival skills. What I was getting at is that the thing you both were interested in on a personal rather than a business level was his website. Unlike his 'professional career' it's something he can take full credit for and which is objectively worth being proud of - it's full of useful content.
My sense is that creating content is what he could be exceptionally productive. Maybe what's called for is an agent and an editor.
Developer work is too varied to have a single consistent voice. Drop the union idea, the word has too much baggage and becomes a huge people management issue. Turn it into what developers do best, build an app/api.
I'm not sure if this idea will make too much sense; I need to see if I can find some time to explore it a little more. I could see building an app/api which is a mixture of a news/issue aggregator and a remote config editor.
Figure out how to surface issues to developers in a consistent way. Then let developers decide which issues matter to them, and how to deliver updated configs. Then let developers decide how to use the api/config from there. Maybe some apps will decide to disable in-app purchases for some time period, maybe some will alter code-flows to use a competitor of a big company, maybe some app will praise some company for their stance on some issue. The developers need to be in full control at all times though. The api would let developers read the remote config from their apps.
Maybe it just turns into a remote config service, and the activism part gets lost... but it might work as a vehicle for this kind of activism too.
Perhaps "union" is too loaded of a word. My intentions was for a body that can collectively bargain on behalf of developers against companies that right now are treating them as they will since as individuals they have no leverage or recourse.
Unions originally worked because they could stop the flow of all labor (union or not) into a job site. Now there is a legal process that avoids the violent bits, but it doesn't really apply to the current situation.
Moreover,the equivalent to a picket line is what, a DDOS? Shit will get you sent to jail, yo.
The structure of desirable APIs <-> Developers makes collective bargaining not super useful.
No, it's much more simple than that. Developers can simply cut their apps from the ecosystem for a short while. Or move to another platform in large numbers. Just the threat of each action should cause those companies to consider some concessions.
You're missing the point. Individual workers or developers are replaceable, and at a serious power disadvantage. A union works by blocking all access to labor, and requiring the company to negotiate with the union alone. Unions used to do this by physically blocking non-union workers from going to job sites, today there are formal legal processes. There is no alternative to either method available to developers for closed platforms. If you opt out of developing for the more lucrative platforms, there are plenty of people willing to replace you.
I know it's more complicated than that and that there are exceptions, and that over time some places become hybridized. I'm still right.
If you live up north, adjust the local schedule instead of the clocks. If kids are waiting in the dark, move the start time to later in the day. If it is light out at midnight shift your schedule so you go to sleep after 12:00am. If you are living your life based on the position of the sun, the numbers on the clock are going to mean something a little bit different everyday anyway.
Time is supposed to have a relatively consistent meaning, and we jump through a lot of hoops to give it an inconsistent meaning. Schedules are much more fluid and easy to change with little external side-effects.
People will need to learn to partially decouple their routine from the numbers on the clock, but that seems like a much simpler/cheaper problem to solve than our current time mess.
Can you imagine how much more difficult that would be to program for? Instead of (relatively) easy to parse timezone rules you have some kind of awful, locale specific agreement that that event you scheduled for 9am monday every week would actually occur at 8am half of the year?
I'm not sure if you are serious, but I don't understand what you think would be involved.
If you remove the time inconsistencies from a calendar, any decent calendaring app will solve the scheduling problem you are left with. Scheduling is a data entry problem. It is a problem we have with or without timezones and dst changes.
http://sqlfiddle.com/#!17/b3d19/1
You can do something similar in MySQL with temp tables.
Bulk update through upsert (slightly different than a bulk update, since it can create rows too)
MySQL: http://sqlfiddle.com/#!9/a6f050/1
Postgres: http://sqlfiddle.com/#!17/a8367/1