"Zbigniew Lukasiak" <[EMAIL PROTECTED]> wrote on 01/24/2008 01:53:08 AM:
> This started with me trying to add some new features to create - they > were rejected because I was using update_or_create and it does not > always work, so I went and tried to fix update_or_create and I found > out that this bug is a result of two things: > > 1. that you need to delete the primary key when you have them > undefined and try to insert the row in PostgreSQL > 2. that when you delete the pk instead of leaving it undef then find > will not work as advertised > > My plead to a workaround for 1) - by simply deleting the PK in the Pg > storage driver was rejected so those that use PostgreSQL are forced to > live with the consequences of using find with the PK deleted. > > 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'mwrong" :) > > The following methods use find and will silently create a new row > instead of using an existing one in that case > > update_or_create > > update_or_create_related > > find_or_create > > find_or_create_related > > find_or_new > > find_or_new_related > > This is even further complicated by the fact that the current > implementation does not do exactly what is quoted above - it tries to > 'guess' what row should be returned - and that means that sometimes it > has the opposite result: the above mentioned functions will silently > update or find an existing row instead of creating a new one. > > > The consequence of that is that you should not use these methods in > libraries where you cannot say "actually I know it does and I accept > you can't help me if I'm wrong" because you don't know what ResultSet > and query you receive. > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ I think this explanation should be bottomed linked on the pod -- this behavior (at least to me) is not expected. -Wade _______________________________________________ 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]
