[Dbix-class] Recursive update_or_create - RFC

luke saunders luke.saunders at gmail.com
Wed Jun 25 10:11:58 BST 2008


On Mon, Jun 23, 2008 at 7:17 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> On Mon, Jun 23, 2008 at 7:49 PM, luke saunders <luke.saunders at gmail.com> wrote:
>> On Mon, Jun 23, 2008 at 9:57 AM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>>> On Mon, Jun 23, 2008 at 12:23 AM, luke saunders <luke.saunders at gmail.com> wrote:
>>> As to the second question - i.e. about eliminating the need of putting
>>> id => undef into the query to indicate that a new record needs to be
>>> created.  One solution is also an additional parameter and one that
>>> would be inside the query structure (because it needs to be supplied
>>> separately for each record).  I don't like that solution - because it
>>> means additional reserved word - something like create_new_row => 1
>>> added for the query params for each new row.  And it would not be
>>> consistent with the case when pk => 'some new value' and you have no
>>> record with such a primary key.  Maybe you have other proposals.
>>
>> Yeah, I don't have anything better sadly.
>>
>> Which kind of makes me think that only recursive update makes sense
>> until an SQLA refactor allows the correct approach for recursive
>> update_or_create.
>
> I hope that this means that you agree with me - at least for now.
>
> For the future with the hypothetical refactorisation - I need to ask
> what you have in mind when you talk about "the correct approach"?
> Analysing the query and checking if it comprises a unique condition on
> the primary key?  And if it does not then don't call ->find - but
> rather go directly to ->create?  The problem is that whatever is your
> refactorisation of SQLA - then still the question if a given condition
> comprises a unique constraint on the primary key is undecidable.  This
> is because the condition can contain arbitrary arithmetics and
> arithmetics is undecidable (Goedel).  So you'll need to define some
> additional constraints on the queries used.    This will much
> complicate the solution.  I don't know if I'd wait for that.

If the condition on the PK contains anything but a straight 'equals
$number' comparison then it's fair to assume that you don't have the
PK. So I think it is possible, it's just not easy.

If pushed on the 'undef' issue then I think the reserved param method
is probably the best way. You could make what the reserved word is
configurable to help the module user avoid clashes, so it's not so
bad. If you were to allow find by unique constraint (as opposed to
just PK) then the user would have to specify which key they want to
find on at each stage of the recursion and the only way to do that
would be in the structure itself, so you would need the reserved param
for this anyway.



More information about the DBIx-Class mailing list