On Wed, Oct 01, 2008 at 09:38:07AM +0200, Zbigniew Lukasiak wrote: > On Wed, Oct 1, 2008 at 3:17 AM, Matt S Trout <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
Ah, because the artist is about to be changed? In that case you should create the artist separately and then assign it I think, which again avoids the problem. Better ideas welcome. -- 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/ _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]