Skip Menu |
 

This queue is for tickets about the DBIx-Class CPAN distribution.

Report information
The Basics
Id: 120271
Status: open
Priority: 0/
Queue: DBIx-Class

People
Owner: Nobody in particular
Requestors: FGA [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.082840
Fixed in: (no value)



Subject: Cookbook section "Changing one field whenever another changes" incomplete
I believe that this section should cover the use case where two fields are strongly related and their values should be kept in sync. In my case it is for instance a filename and a SHA1 checksum. I would like for the checksum to always be calculated from the file (something a DB default will obviously not be able to do), unless provided manually by the user for some obscure reason. Keeping this in mind, when using the example from "Changing one field whenever another changes", there are two use cases left unimplemented: * creating a new Row with "path" set to non-undef * calling ->update({ path => 'something' }) In both cases the custom mutator from the example is not called. I am not sure what to do about the second case -- is it enough to overload update() ? The first case can be easily handled by overloading new() as described just above in "Setting default values for a row". I can provide a doc patch in a PR if you want, assuming you can confirm that overloading update(), new() and the accessor is enough to cover all bases.
Download (untitled) / with headers
text/plain 678b
On Thu Feb 16 14:28:19 2017, FGA wrote: Show quoted text
> I can provide a doc patch in a PR if you want, assuming you can > confirm that overloading update(), new() and the accessor is enough to > cover all bases.
Actually... I am afraid it isn't. You also need to decide what to do when store_column ( distinct from set_column ) is called, and also need to figure out what happens if someone does a partial-fetch from the database ( i.e. only one column is brought in - this would be controlled via inflate_result ) Other than that - yes, it would be useful to write something up. The ::Row interface was woefully under-designed back in the day, and we are kinda-sorta stuck with it now :/


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.