On Wed, Oct 1, 2008 at 3:17 AM, Matt S Trout <dbix-class@trout.me.uk> wrote:
> On Tue, Sep 30, 2008 at 02:39:00PM +0200, Zbigniew Lukasiak wrote:
>> On Tue, Sep 30, 2008 at 2:20 PM, Matt S Trout <dbix-class@trout.me.uk> wrote:
>> > On Tue, Sep 30, 2008 at 09:28:50AM +0200, Zbigniew Lukasiak wrote:
>> >> The tricky part is when you load data from the form into the new row.
>> >> You need to delete the pk from it - because otherwise at
>> >> update_or_insert time it would issue an insert with pk = NULL - and
>> >> this will fail in Pg (for example). The point is that you cannot feed
>> >> the same data to the find and to the insert calls - but
>> >> update_or_create does that - and why it does not have much choice is
>> >> another very long story.
>> >
>> > Well, yes. If you have an auto-increment PK and you don't have a value for
>> > it, then
>> >
>> > (1) there's no form field in the first place, so that's not an issue
>> >
>> > (2) you know you can't possibly find anything, so you wouldn't call
>> > update_or_create, you'd just call create
>> >
>> > I presume this is what Oliver's doing, which is why his code works.
>> >
>> > Nothing tricky at all.
>>
>> This method assumes that you don't get the PK in the ResultSet in the
>> internal conditions. I is ok if you have the full controll over the
>> ResultSet - but if you do admit this possibility (for example when you
>> traverse a belongs_to relation, or if you use RestrictedWithObject) -
>> then you would have to inspect it o check what part of the PK is there
>> to decide if you should go directly to ->create. Since currently
>> there is no easy and sound way of doing this inspection (and for some,
>> rather convoluted - I admit, cases it is impossible - that is it is
>> undecidable - i.e. cannot be solved by an algorithm) - this makes this
>> method unsuitable for my purposes.
>
> I don't see that this would ever happen with an auto-inc PK though.
>
> And if it's a unique key, the behaviour is rather different.
>
> Basically, I've not yet seen a real world example where this situation
> actually comes up, and I can't think of a contrived one that doesn't come
> into the category of "your design is broken".
>
> So it's so far a problem in theory but not in practice - can you provide
> a real example of this situation?
The example that I am mostly concerned with is:
$cd_rs->recursive_update( { title => 'New Title', artist => { name =>
'New Name' } } )
Now when traversing the relation from cd to the artist I get the
artist resultset with the PK constrained in the ->{cond}. There is
just one artist that the cd 'belongs_to' - and that artist should be
updated. But there is no PK passed in the parameters - so if we just
look at the parameters we would conclude that this would require a
->create call.
If someone uses add_relationship instead of the ('belongs_to' or
'might_have' ) helpers - this becomes even more untraceable.
For a slightly more contrived example let's take User and Notes just
as you have at:
http://search.cpan.org/~groditi/DBIx-Class-Schema-RestrictWithObject-0.0001/lib/DBIx/Class/Schema/RestrictWithObject.pm, but let's assume that the Notes table has a composite primary key
that contains 'user_id' and 'subject'.
Then one would expect that this:
$restricted_notes_rs->update_or_create( { subject => 'Some existing
subject', some_other_column => 'New Value' } )
would result in updating the Notes record with ( $user_id, 'Some
existing subject' ) in PK rather then trying (and failing) to create a
new record.
Highlight