[Dbix-class] find redux

Matt S Trout dbix-class at trout.me.uk
Mon Feb 18 17:10:10 GMT 2008


On Mon, Feb 18, 2008 at 01:36:08PM +0100, Zbigniew Lukasiak wrote:
> On Feb 17, 2008 4:58 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > >
> > > Now, waiting for this to be committed, here is the problem with the
> > > *_or_* methods: Pg will not accept an INSERT with the primary key set
> > > to NULL and on the other hand the "find" method will not accept a
> > > query without the primary key.
> >
> > I don't understand why you'd want to find() when you don't have a key to
> > find by?
> >
> > What's your use case for passing undef to find_or_create at all? Surely
> > in this case you should just be calling create?
> 
> The idea is to have a method that would check the parameters passed to
> it and do the right thing.  Of course you can check the parameters
> yourself - and then call find or create yourself - but then you don't
> need find_or_create.  And if you want to do it in a generic way (lets
> say when you write a library) then you'll end up with a function very
> similar to find_or_create and with the same problems.

No. find_or_create is for "I have a unique key value and want to ensure
it's there".

It's -not- for "my library is too fucking stupid to tell me if this is a
create or an update form".

There's no comprehensible reason why you'd want to find_or_create for an
autoinc PK. That just means you've got broken code upstream.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/



More information about the DBIx-Class mailing list