[Dbix-class] A more accurate redux of zby's comments

[Zbigniew Lukasiak]

On Jan 25, 2008 12:30 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Fri, Jan 25, 2008 at 10:10:45AM +0100, Zbigniew Lukasiak wrote:
> > On Jan 25, 2008 8:07 AM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > > >  what would that
> > > > 'proceed as normal' mean? Would it mean that the uniqueness is not
> > > > checked at all, the query is reduced by all columns that don't belong
> > > > to any of the unique constraints (or that don't belong to the chosen
> > > > unique constraint), then it is run and the first row is returned?
> > >
> > > It would mean that DBIC would accept the user saying "I know you can't tell
> > > but this is unique". Possibly we should also check to see if the sth is
> > > exhausted after getting the single row and produce a warning or exception
> > > if not.
> >
> > Great!  That is what I believe is needed.
>
> I believe a warning in Storage::DBI's single() method would do the trick.
>
> > > >
> > > > When you do know the PK then you would call find, when you do know
> > > > that you have no PK then you would directly call create or new.  It is
> > > > only when you don't know that you need any of these listed methods.
> > >
> > > I think you're (a) assuming PK rather than one of N unique keys, (b)
> > > assuming an auto-increment or other surrogate PK rather than a natural one.
> > >
> > > Much of the utility of the *_or_* methods is when one or both of these is
> > > not the case.
> >
> > It's hard to analyse that without use cases.  Here is the one that I
> > was mostly thinking about:
> >
> > Code to edit/create a record from web form parameters.  You receive a
> > bunch of columns and you need to update the record identified by the
> > columns that form the PK or create a new one if there is no such
> > column (including the case when the PK parameters are set to 'undef'
> > so that they would receive the default value from the DB).   It would
> > be very useful to have a method on the resultset that would
> > automatically analyse the parameters and do the right thing.
> > update_or_create is unfortunately unsuitable for that - because you
> > cannot delete the PK from the list of parameters even if it is undef
> > (otherwise find will not always work as expected) and you cannot leave
> > it there if it is undef - beause then create will fail.
>
> Ok, but as I've already noted the fact that deleting it buggers up find()
> is a bug (personally I think not knowing whether the operation is a create
> or an update is also almost always a bug, but that's a matter of taste)
>
> $rs->update_or_create(\%params, { key => 'primary' })
>
> -should- be safe in this case, provided you don't pass undef for the PK
> which means "try and INSERT NULL" not "receive the default value" - as Carl
> noted that's a bug in FormFu and DBIC behaves correctly in the { id => undef }
> case.

I'll come to this later after we settle down on the desired semantics.

>
> Note, by 'should' I do mean should, not 'is'. But I already started a
> thread to discuss the behaviour of find etc. and how to fix it so please
> post about that there, not here - the ones you started had got hopelessly
> confused because your writing style tends to be wordy and vague (several
> people have commented they were lost which is why I started the fresh thread)
> and bullet points and concision work rather better to summarise technical
> issues ;)
>
> > And just to explain myself - I really try to contribute to the project
> > - and I hope that this documenting of the gotchas that an
> > unexperienced DBIC programmer can encounter when using it is a
> > contribution and not an evil attack.
>
> Certainly, if you document clearly and accurately. The post of yours that
> started this thread was neither and as an added bonus quoted me to support
> a point that wasn't actually what the quote was referring to.
>

You repeat that accusation of quoting you out of context - but in fact
I did try to bring the context with a short introduction - if it was
not entirely what you had in mind then I am sorry.  But to defend
myself I'll copy that whole part of our conversation here with some
underlinings:

> > First about the nature of the problem. When called on a ResultSet
> > object find tries to determine if the query it receives and the
> > internal conditions of the ResultSet object do include at least one
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > full unique constraint (for example a primary key). But it is not
> > always possible to do that. Let me quote from one of the core
> > developers about that problem:
> >
> > > Of course you can't always determine. But if you don't know, then you default
> > > to "no it doesn't produce a unique row" and provide some way for the user to
> > > say "actually I know it does and I accept you can't help me if I'm wrong" :)
>
> I was talking about join conditions there and introspection onto those.
>
> Please don't quote me out of context.
>
> My comments there were for the *_related stuff - that it couldn't -always-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> be possible to know that a join condition would result in a unique record
> on the other side, but that we should provide a flag to allow the user to
> specify that they know it -does- and DBIC should proceed as normal.

So I wrote about the general case of having additional conditions in
the ResultSet - while you were talking only about the *_related stuff
(which is just a specific case of the same thing).  Perhaps I
misunderstood you - but I would say it was just a minor difference.


Cheers,
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/