lattepiu

I can comment on Amazon Aurora:

> Is the product a fork of PostgreSQL or a wrapper round the current version?

Aurora is a fork: they've re-written a significant chunk of the engine. Note that Amazon also offers RDS PostgreSQL, which is a managed version of the "regular" PostgreSQL engine. RDS PostgreSQL also offers a HA setup (no version upgrade without downtime, however). It works quite well.

> Will the DB engine keep in lock-step with new PostgreSQL releases or might they diverge?

Amazon promises to keep it in lock-step. How soon they will release an upgrade to a major version remains to be seen.

> When new versions of Amazon Aurora/Azure DB for PostgreSQL are released will our live instance get automatically updated or will we be able to choose a version?

Minor version upgrades are applied automatically. For major version upgrades, it's unclear at this time (there hasn't been one yet for Aurora PostgreSQL), but I think it's unlikely they will be applied automatically.

Olive oil is actually excellent for frying. Extra virgin olive oil has a smoking point of 405 deg. F, which is similar to canola.

Something is quite wrong indeed. I disabled the dynamic pager, and now my system is working as it's supposed to. Snappy and responsive.

I opened all of my apps, expecting it to crash miserably: instead, the system started paging as it should, stayed responsive (though slower), and promptly returned to normal once it regained memory.

I don't know what's going on, but I can definitely say that this is how I want my computer to work.

The real culprit here is HashWithIndifferentAccess, a crutch that throws away a difference that Ruby has for a reason.

The sensible way to do updates, in my opinion, is

    User.update(:name => params['user']['name'])

But there's no way in Rails to keep that syntax while disabling

    User.update(params['user'])

Three years ago the state was much worse, so I ended up writing my own ORM, which tries to address some of the issues pointed out here.

My primary need was to be able to map the same models to different schemas, including very badly designed legacy ones, so the mapper layer had to be clearly separated from the model and very hackable. Also, the query syntax had to be powerful enough to avoid SQL whenever possible, so that the same queries could be applied to different environments.

Right now it implements Units Of Work and Identity Mappers; it has deep querying and multilevel strategic loading (not limited to one level as with DataMapper); functions and aggregates; and many other features, wrapped in a familiar easy syntax.

If someone wants to try it, I'd love to hear some feedback: it's at https://github.com/me/spider.

I don't believe this is a good example. Ruby has case..when instead of COND, though it's a language construct, not a function; but I think COND can be trivially implemented in any language that has anonymous functions. In Ruby:

  def COND(*args)
      args.each_slice(2){ |s| return s[1].call if s[0].call }
  end

  COND(lambda{ false }, lambda{ "not this"}, lambda{ true }, lambda{ "this" })

(not a lisper, though, so I might be missing something).