Could Better Testing Practices Have Prevented the Healthcare.gov Defects? • Hacker News Board

Re: Could Better Testing Practices Have Prevented the Healthcare.gov Defects?

#51

Post by Pxtl » Tue, Oct 08, 2013, 11:35 PM UTC

jrochkind1 wrote: post #47

Pxtl wrote: post #27

Earlier quoted context omitted.

The big thing with an ORM is that you must keep those lazy loads in mind when you work with it. Lazy loads are the big place where you get "300 queries instead of 1". ORMs aren't bad on principal, imho... but they give you more than enough rope to hang yourself while promising a magical efficient user-friendly rope.

I wonder why most ORM's don't let you turn off lazy loads -- "only fetch when I ask for a fetch, if I try to access something without having asked you to fetch it first -- raise an exception!" Just as an option. This would not be a particularly difficult feature for an ORM to implement.

Microsoft's LInQ2Entities offers this. In 3.5 it was on by default, but EF3.5 was the buggiest mess ever. They rushed it out when they realized that LInQ2SQL was unmaintainable, and then made an even worse mess.

It offered a manual "Load" operation that manually initiated the lazy load for a given FK relation, providing a worst-of-both-worlds option.

The thing I could never figure out in LinQ was how to make an explicit load of related objects fetch more aggressively. Like, say I have object Foo. I find out I need Foo->Bar, but realistically I'm also going to need Bar->Baz and Bar->Quux to make Bar useful. I could make a stand-alone query to pull down Bar, Bar->Baz and Bar->Quux in a single query, but then Bar wouldn't be loaded attached to Foo, and if I attached it to Foo it would confuse the object context. I could use the Foo->Bar to load Bar, and then Bar->Baz and Bar->Quux to load Baz and Quux... but that would be too many hits to the DB. I could never figure out how to put those things together, and fetching Foo->Bar->[Baz|Quux] proactively every time I wanted a Foo wasn't preformant.

Of course, this was back when I was obsessed with normalization and was using UUIDs for all my primary keys, so I might be missing the point.

Re: Could Better Testing Practices Have Prevented the Healthcare.gov Defects?

#52

Post by jrochkind1 » Thu, Oct 10, 2013, 2:18 PM UTC

Pxtl wrote: post #51

jrochkind1 wrote: post #47

Earlier quoted context omitted.

I wonder why most ORM's don't let you turn off lazy loads -- "only fetch when I ask for a fetch, if I try to access something without having asked you to fetch it first -- raise an exception!" Just as an option. This would not be a particularly difficult feature for an ORM to implement.

Microsoft's LInQ2Entities offers this. In 3.5 it was on by default, but EF3.5 was the buggiest mess ever. They rushed it out when they realized that LInQ2SQL was unmaintainable, and then made an even worse mess. It offered a manual "Load" operation that manually initiated the lazy load for a given FK relation, providing a worst-of-both-worlds option. The thing I could never figure out in LinQ was how to make an expli…

Intersting.

But to be picky, let's note that "manually initiated the lazy load" -- there's nothing "lazy" about that load, heh. The "lazy" part specifically means "on-demand, as asked for, automatically."

In ActiveRecord, you can quite easily set 'eager loading', which is setting certain loads to batch for efficiency, like you're talking about -- and this can apply to lazy loads (when you lazy load X, ALSO load y and z together, in as few SQL statements as possible), OR to manual loads (right NOW, load x, y, and z together in as few loads as possible). But AR doesn't let you turn off lazy loads, ha.

Re: Could Better Testing Practices Have Prevented the Healthcare.gov Defects?

#53

Post by ericras » Thu, Oct 10, 2013, 3:29 PM UTC

snowwrestler wrote: post #50

dragonwriter wrote: post #41

Earlier quoted context omitted.

One side effect of the complexity of government contracting processes (designed, in principle, to ensure that the government doesn't get taken advantage of by either internal or external actors) is that the people who get awarded government contracts are often the people with the most skill in negotiating the government contracting process, not the people with the most skill in the problem domain.

We know who built Healthcare.gov; it was Development Seed. There were a bunch of stories about it earlier this year. Development Seed also built and runs MapBox, so they should have some idea how to run a high volume web service.

And the front end built by Development Seed has had no problems. It's been the marketplace built by another contractor.

Re: Could Better Testing Practices Have Prevented the Healthcare.gov Defects?

#54

Post by ErikAugust » Sat, Oct 12, 2013, 6:20 PM UTC

camus wrote: post #25

ErikAugust wrote: post #19

Earlier quoted context omitted.

"Slow DB queries are the enemy and you don't realize how bad they are until you are at scale. Sure, it only takes a few seconds on your local machine, but multiply that times thousands of concurrent users and your DB gets swamped. If you are using an ORM, it is MUCH harder to track down where in your code that 3 way join that scans every record is happening. Ideally you'd be using straight SQL and maybe use comments…

Problem is your ORM might generate 300 fast queries to get 300 records where 1 would be faster than 300. using an ORM make things tricky since you basically surrender most of Db control . Scaling databases is hard,developpers like ORMs , but ORMs make scaling databases even harder.

I see - I don't use ORMs outside of a small Django app.