[Dbix-class] Adding UNIQUE constraint support

[Daniel Westermann-Clark]

On 2005-12-16 20:15:56 -0600, Brandon Black wrote:
> There's been discussion in PostgreSQL of having a native operation for
> this, which will probably end up being called either "UPSERT"
> (UPdate/inSERT) or "REPLACE" or be a part of the MERGE functionality

Interesting, I hadn't heard that. Can't say I would mind such
functionality.  :)

> Second, I don't think what you're doing is really the same as
> ->find_or_create() anymore.  I would call it something more like
> ->update_or_create(), or ->create_or_update(), and leave the
> original alone as it was.

You've got a good point.  I set out to make the component a drop-in
replacement for find_or_create, but it really doesn't do what the
method name implies.  The method is now named update_or_create.

> It would make more sense for your function to consider the PK as
> part of the set of UNIQUE keys as well.

Good idea, I've added this.

> And the api for defining UNIQUE keys should probably mirror that of
> PK's as much as possible.

You can specify multiple UNIQUE constraints currently, each with one
or more columns.  Are you suggesting the interface be simplified?

> I'd call them "Alternate Keys" or "Secondary Keys" instead, since
> that's more of a generic relational theory term, whereas UNIQUE is
> sql-specific.

Yeah, I went back and forth on the naming for a while, then settled on
Constraint::Unique.  I figured maybe this would fit better for the
future, if other constraint types are added.  I could probably still
be convinced to change the name, though.  :)

> In any case it's a definite improvement over the current situation
> even if you choose to keep everything the way it is.  Don't take my
> long critique as a bad thing :)

Thanks for taking a look.  If there are any further suggestions, I'd
be happy to try them out.

-- 
Daniel Westermann-Clark