>>>> That said, there's a few things that I'd like to see be done:
>>>> 1) With one setting, I should be able to turn on validation for
>>>> all my columns that have a type set for them. So, if I have a
>>>> column that is an integer, that should just turn on for me.
>>> Ok, on which level ? For a single model, for all models with
>>> columns of a certain type globaly (see 3) or at runtime (eg
>>> before the actual update/create.. something like
>>> $object->validates( $data_ref, { exclude_types => [ qw/ integer /
>>> ] } ) ? What use-cases can you imagine for this (for my better
>>> understanding of the requirements) ? For my use, the decision
>>> which validator(s) or none at all to use was sufficient, so far,
>>> but that doesnt mean anything ..
>> Frankly, I am of the opinion that if you have DataValidation as one
>> of your components, any of your columns with a type should at
>> least validate against that type. This would seriously help with
>> SQLite usage.
>>
>>>> 2) I should be able to chain validations. So, something like
>>>> "validation => [ 'foo', 'bar' ]". Look at how Moose does this.
>>> I'm not quite sure wheter this is not already implemented. Right
>>> now, you can provide multiple validators for
>>> (update|update_all|create)_validated and the validates method
>>> itself. These will by applied one after another, thus chained.
>>> Eg: $object->validates( $data_ref, qw/ validator1 validator2 / );
>>> That's what you meant, or am i missing the point ?
>> That works.
>>
>>>> 3) Different DBMSes have different types. So, maybe
>>>> producer-specific validations would be helpful (q.v. #1).
>>> Sounds very intersting. I could imagine validation-set-modules,
>>> one for every DBMS, like DBIx::Class::DataValidator::MySQLTypes.
>>> Then one should be able to enable/disable a subset of validation
>>> types.. eg __PACKAGE__->mysql_validation_enable( qw/ :all / );
>>> __PACKAGE__->mysql_validation_disable( qw/ date datetime / ); If
>>> you do this in your super-model (from which all inherit) this
>>> would apply globally. If you switch the DBMS now, you simple load
>>> another module like DBIx::Class::DataValidator::PostgresTypes or
>>> so and all the special columns for this DBMS will be validated.
>> Bah. Autoload that crap based on the storage_type I already told
>> DBIC about in my DSN. Don't make me hardcode anything.
>>
>> Rob
>>
>
> Alright then, i'll look into it at the weekend. The validation via
> DBMS determiniation looks like a goode idea. Thanks.
> Ok, i've updated the modules concerning your ideas. A db-type aware validation would be auto-loaded and applied, if not disabled. But, as Eden wrote, the DBMS stuff will be added in DBIC 0.9 anyway, so i kept it most simplistic and modular, that it can be removed later on and doesnt make me to waste much time now. Further, i'm not sure "how much validation" will be part of 0.9 and if this module (even without the DBMS stuff) is not totally obsolete when DBIC 0.9 releases. However, i need validation (especially for profiles) right now and cant wait for the release. Could'nt find any any date, though. I've updated the documentation to explain the ideas and possibilities of this module. Following i've pasted an excerpt, which should explain most of it briefly and doesnt make me write it twice: *********************** [...] a short introduction of the multiple approaches and methods you can follow to achieve validation. Most of them could be combined and are not "either-or". * Validation profiles These are ment to be used in most complex validation scenarios. You can validate the data with multiple profiles (one after another, chained) with one call. * Inline column validation Directly in the column definition via add_column they are most simple and fast. Also the definition of the columns is not apart from the defi‐ nition of the validation. They are limited because they have to fit always (each save) and cannot be used, as validation profiles, only in certain circumstances. You can easily use them in addition to validation profiles or exclusive. In the first case they’ll run before the validation profiles. * DBMS specific validation This is a kind of auto-validation for basic datatypes of your column. They are DBMS dependent. So Oracle DB might have some types which Post‐ greSQL has not and vice versa. Also the dates for PostgreSQL DBs and for MySQL DBs look different. They normally apply per default if you dont deactivate them manually (see below). They are overwritten by your custom inline column validation. They can be understand as a kind of default inline column validation. * Named validation methods Those could be used either in inline column validation or validation profiles alike. This is simply an approach to outsource often used vali‐ dation methods or regular expressions to reuse them in multiple models and/or for multiple columns. * Validation column classes Another approach to reduce code in your models by pre-defining. This includes more then the basic datatypes (you can say each integer column is an integer-class column) by allowing custom and complex validations. They can also used for non validation purposes (just dont use the validation key). Named validation methods are of course usable. Probably you should define those classes in a super model from which all your other models inherit to get the most benefit out of it. *********************** Please read the POD in DBIx::Class::DataValidator for more info.. Despite what i wrote above about 0.9, i think i could provide DBMS specific validation for MySQL and PostgreSQL before i release this to CPAN (but in sepparate packages, due to dependencies), but first of all i would like to hear what you all think about the usefullness at all. Nice weekend to everybody! Ulrich
DBIx-Class-DataValidator-0.02.tar.gz
Description: GNU Zip compressed data
_______________________________________________ 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/dbix-class@lists.scsys.co.uk
