DBIx::Class, another data validation approach
|
| 1 2 |
|
Hello all
sometime ago i wrote a data validation module for validation right in the model. I didnt published it yet, and now i searched the list and found DBIx::Class::Validation. However, i thought about using this one instead, but the migration would be to extensive for me and i think it does not fit my needs.. Hope this isnt too confusing; in the attachment is my idea of validation (DBIx::Class::DataValidator). Any tests, critics and ideas are welcome. I would upload it to CPAN as soon as is find time to clean the docs and write some more tests (the included should work). Greets from Berlin Ulrich Kautz _______________________________________________ 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@... |
||||||||
DBIx-Class-DataValidator-0.01.tar.gz (17K)
|
|
||||||||
|
|
|
||||||||
|
|
||||||||
|
|
|
||||||||
|
In reply to this post
by Andy Armstrong
|
||||||||
|
|
In reply to this post
by Rob Kinyon
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
In reply to this post
by fREW Schmidt
|
||||||||
|
|
|
||||||||
|
In reply to this post
by Rob Kinyon
|
||||||||
|
In reply to this post
by Ulrich Kautz
|
||||||||
|
|
In reply to this post
by Ulrich Kautz
>>>> 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. > 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 _______________________________________________ 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@... |
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
>> --%<-- >>>> [...] 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. >>>> >>> I'm not completely sure what you mean by this. Are you trying to >>> say that column validation is used for both inserts and updates >>> no matter what profile you are using? >> Yes, column validation always applies! In opposite to profiles you >> can't trigger them on or off, especially there is no trigger to >> switch only certain column validations on or off (as you can do >> with profile validation). Excuse my poor english, little bit out of >> practice, i'll try to write it more clearly.. >> > > Well, at some point I'm sure that once this is in a public repository > you could convince some of us to do some doc for you, that way you > can focus on what you're already good at :-) >> >> --%<-- >>>> 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 >>> >>> Thanks for spending your time on this! I looked through your >>> tests and briefly read some code and I think this will do quite >>> nicely. Just a couple questions: does it only validate when you >>> call create_validated or can you have create validate by default? >>> Same for update and the $rs version of update. >> No problem, actually i'm using this - so i do benefit myself ;) >> >> Yes, validation is only performed on >> (update|update_all|create)_validated. Maybe this is a based on the >> development history. I merged a (Catalyst) app, where i use this, >> slowy from controller validation to model validation. However, i >> think its more readable if you still use both (validation and no >> validation) - especially for the profile validation (at which you >> provide the profile names as 2++ arguments), but i can implement an >> "enable_native_validation"-switch, or so. A possibility to use the >> "non-validation"-methods should always exist. >> > > I think that sounds great. enable_native_validation probably > wouldn't complicate things significantly and having *_non_validated > (or something like that) methods would allow you to bypass it if you > really need to. If you'd like some help with doc, tests, or smallish > features I'd be glad to throw some time into this. I've attached the updated module with the native-validtion thingy. Ulrich _______________________________________________ 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@... |
||||||||
|
|
In reply to this post
by Alexander Hartmaier
|
||||||||
|
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
