[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