[Dbix-class] Recursive update_or_create - RFC

[luke saunders]

On Thu, Jun 19, 2008 at 1:29 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> In the attachments you'll find  DBIx::Class::ResultSet::RecursivePUT -
> it is a base class for ResultSets and it provides just one method:
> recursive_PUT which works just like update_or_create - but can update
> a whole tree of related records.  I wrote it as a method for REST PUT
> operations, i.e. creating and updating complex objects.  There is one
> more difference from update_or_create - it will work on tables with
> auto_increment primary keys - you just need to set the key to 'undef'
> - then it will be deleted from the INSERT sent to the database (this
> will only happen for auto_increment keys - other columns will be set
> to 'NULL' just as usual).  This is additional complexity of the
> semantics - but with the benefit of more universal and uniform usage.
>
> I am waiting for comments - especially about the names - and also
> about the interface.  I am thinking that perhaps the object oriented
> interface creates too much hassle for the programmer as it requires to
> explicitly set up the ResultSet classes - while normally they can be
> omitted.  So maybe I should change the interface to a simple
> procedural interface and change $rs->recursive_PUT( $update_hash ) to
> recursive_PUT( $rs, $update_hash).  What do you think?  Any other
> comments are welcome as well.

so essentially this provides another $rs->update_or_create which can
work recursively, right? so if that's the case then why not just
override the normal $rs->update_or_create method rather than providing
another one? which then begs the question, if this is worth having at
all, then maybe it should just be part of DBIC itself. though if this
were to be a separate ResultSet class, then I wouldn't call it
RecursivePUT - it's nothing to do with PUT requests really - so maybe
RecursiveUpdateOrCreate or something.

i don't quite follow the point about it working with auto increment
PKs. are you just saying that if you provide { pk => undef } to the
existing update_or_create implementation, it'll try to insert a row
with a NULL PK? but presumably it won't do that if you don't set the
pk at all, so I'm not sure I see the problem.