Hacker News Reader

Comment by masklinn | Hacker News Reader

The short log is missing one of the most important and awesome new feature to application writers: a bunch of new PQresultErrorFields[0] on constraint failure, providing access to (context-dependent) the raw schema name, table name, column name, constraint name and datatype involved.

Previously these remained locked into the database and to get programmatically-useable info (for logging, better error messages or to translate in terms of e.g. your ORM) you had to parse error messages which were potentially localized and usually lacked half the necessary information.

And even better, for python developers, psycopg2 already supports these fields[1][2]

[0] http://www.postgresql.org/docs/devel/static/libpq-exec.html#...

[1] http://psycopg.lighthouseapp.com/projects/62710/tickets/149

[2] http://initd.org/psycopg/docs/extensions.html#psycopg2.exten...

View on HN

Where would one find out if anyone is working on a patch for ActiveRecord?

The Rails/ActiveRecord bug tracker?

edit: the underlying connector might be a better idea to start with, as it'll need to expose the fields somehow before an ORM can take advantage of them.

Looks like work has started on the underlying connector: https://bitbucket.org/ged/ruby-pg/issue/161/add-support-for-...

I wouldn't say "work has started" when the bug has just been reported.

This is where you'd want to be looking in the source: https://github.com/rails/rails/tree/master/activerecord/lib/...

Specifically at any error handling, which I think would likely be here:

https://github.com/rails/rails/blob/master/activerecord/lib/...

https://bitbucket.org/ged/ruby-pg

I think it can use either pg (wrapper around libpq) or postgres-pr (pure ruby), though I always use pg.

EDIT: Seems like they have dropped support for postgres.

EDIT2: Yes, I did mean postgres-pr.

Do you mean postgres-pr? (postgres is marked as a deprecated gem to replace with pg)

I think ActiveRecord pattern is more limiting you than helpful. I found the following post quite interesting: http://mindref.blogspot.com/2013/02/sql-vs-orm.html

ActiveRecord doesn't even support constraints in the first place.

Shameless plug: here is a gem I wrote to manage foreign keys and CHECK constraints (and also indexes) in a Rails project:

https://github.com/pjungwir/db_leftovers

What do you mean by "support constraints"?

If I, for example, violate a unique index, a ActiveRecord::RecordNotUnique exception is raised.

Is that true? I might be wrong about this, but I think ActiveRecord checks for uniqueness (and other constraints) in application code, generating an extra database query if needed. If you _actually_ violate the unique index, a PGError is raised (if using postgres).

No. ActiveRecord checks for constraints on top of what the database offers. You are free to specify database constraints if you like. In older versions of ActiveRecord, uniqueness errors generate a generic database exception. In recent versions, uniqueness errors generate the specific exception RecordNotUnique.

Wow, that is awesome and is something I've been worrying about recently. However, there is a second part that is still missing that would allow for actual postgresql application development. There needs to be a way to check all constraints and report all failures, rather than just stopping at the first error. Without that, users submit data, get an error for one field, fix it and resubmit, get an error for the next field, etc, etc. Reporting all the errors the first time is really important for usability. So right now you have to duplicate all the database constraints in your app, which is a huge source of code duplication (and thus bugs).

"check all constraints and report all failures"

Interesting point. Foreign key failures are usually the result of a program bug. Unique and exclusion[1] constraints depend on concurrent actions, and can't be caught ahead of time as easily. So I assume you are mostly talking about CHECK constraints.

Also, we're talking about a single statement, which probably means a single table.

It does sound like a good idea to validate all of the check constraints on a table at once, and report all of the failures.

[1] http://www.postgresql.org/docs/current/static/ddl-constraint...

Yes and no. Yes in that I am talking specifically about check constraints when I say that we have to duplicate them all in our apps. You can't really duplicate the others. But no in that I don't mean to validate only check constraints and report all failures, ideally it would do unique and FK too. If there's an underlying reason that isn't feasible, then doing all the check constraints at once would certainly be a big improvement though. We're already in the position of having data validation type checks done separately from uniques now, so that would get users of our apps the current behaviour while letting us delete a bunch of code.

FWIW, we try very hard to not write any check constraints and do any such validation at the protocol level, before the request even hits the authn/authz layer. (Spyne makes it easy ! http://spyne.io)

>FWIW, we try very hard to not write any check constraints

I like check constraints. I would never consider removing them under any circumstances, I've dealt with far too many databases full of inconsistent data. I'd just rather not have to duplicate them (or triplicate, etc) in each of my apps that accesses the database.

Reply on news.ycombinator.com