[Dbix-class] Proposed DBIx::Class::Validate Changes

[Christopher H. Laco]

Aran Deltac wrote:
> On 5/12/06, Christopher H. Laco <claco at chrislaco.com> wrote:
>> /claco arises from the land of the dead
>>
>> Now that I've ditched a majority of my distractions (a zillion email
>> lists and rss feeds, irc, icq, im, etc), I've finally got a good
>> foothold on the Handel redesign using DBIC schemas.
>>
>> So far so good; great in fact. One of the changes I'm making is to move
>> towards using Validate as a replacement for the old CDBI constraints. A
>> couple of hacks later; making my Exception/Constraint::check pretend to
>> be FormValidator::Simple, everything is pretty much working. The only
>> feature I can't replicate is the fact that CDBI constraints could
>> actually change the column values if they needed to.
> 
> Initially this seems better suited for inflation/deflation.  Do you
> have examples of how this would be useful?

In my case, the cart items in Handel have a quantity field. There are
two modes of operation on the quantity: a) it is what it is, as long as
its >1, and b) the site sets a CART_QTY_MAX, whereby if the max is 5,
but the user puts in 8, the quantity is reset to 5.

Under CDBI, this was done using constraints, and the fact that CDBI
constraints could alter the column values before they were saved.

I was one line away from doing the same in Validation.

> 
> One example that comes to mind for me is some people like to store
> phone numbers with only the digits - none of the formatting
> characters.  But, this is a case where I'd almost rather have a
> deflator that could deflate to just digits no matter the format, and
> inflate to a nicely formatted number.


Right. I agree, altering the actual format of a string is inflate/deflate.

I'm talking about actually altering ("scrubbing") the value permantently
before it hits the database for storage. Once it's done and in the db,
it will never be altered by another inflate/deflate  sequence again
(unless the user alters the value or course).

> 
>> Since this is apparently not possible in the Validation module, I'd like
>> to propose the following minor change:
>>
>> Allow validate() to call set_columns() with the \%data it already has
>> upon success():
>>
>>> sub validate {
>>>     my $self = shift;
>>>     my %data = $self->get_columns();
>>>     my $module = $self->validation_module();
>>>     my $profile = $self->validation_profile();
>>>     my $result = $module->check( \%data => $profile );
>>>     if (blessed $result && $result->success()) {
>>>       $self->set_columns(\%data);
>>>       return $result;
>>>     } else {
>>>       $self->throw_exception( $result );
>>>     };
>>> }
>> I don't think that should effect anything else, but the tests will tell
> 
> Right, that wouldn't hurt anything as far as I know.  But, it seems
> like the wrong point in the logic to be updating fields through
> validation.

Maybe so, but since it was 99.9% of the way there, I didn't yet see a
need to reinvent another wheel. ALmost all of my old cinstraints are
true validations (id=~uuid, shopper=~uuid, name~-undef, etc), but
quantity was the oddball.

> 
>> the story. If no one has any objections, I'll work up a patch.
> 
> That would be great if you can talk me in to it.

Here's my only argument for: with that change, Validation becomes much
more flexible.

But if not, no big deal. It's not like I can't subclass, and tweak
validate() for my own evil purposes. :-)


  :)  Also, Matt wants
> me to move Validate to a separate distro.  I'll be doing that this
> week.
> 
> Aran


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20060514/cfbfd5c1/attachment.pgp