[Dbix-class] find redux

[Zbigniew Lukasiak]

On Feb 18, 2008 6:10 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> 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.

The use case for me (and it is about update_or_create) is about
editing related records on the same form. I get back some records and
I need to decide if this is an update or a create.  At the mailing
list I have seen other people trying to use the *_or_* methods in
similar ways.

Certainly  there are workarounds for this so if no one else finds it
useful then I give up.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/