There are two reason it is done this way:
1) one reason is that if a check fails there must be a way to report
to the users. Forms have a mechanism for this but db.table.insert does
not, in general
2) if you want the check done in insert you can call
db.table.validate_and_insert
3) there is no way to guarantee checks at the db level in every case.
Consider this:
db.define_table('ab',Field('a','integer'),Field('b','integer',requires=IS_IN_IN_RANGE(0,10))
for i in range(100):
db.ab.insert(a=i,b=0)
db(db.ab).update(b=db.ab.a) # <<<<<
there is no way to enforce this constraint without looping and
checking each individual record. That is very expensive.
Massimo
On Mar 23, 2:57 pm, Jaunx <[email protected]> wrote:
> Logically -- without much web2py familiarity -- I would think that the
> constraints specified in the model would be be applied absolutely
> anywhere the model is used. So when you have a constraint like in the
> example model:
>
> db.purchases.quantity.requires=IS_INT_IN_RANGE(0,10)
>
> The model would prevent any integer outside of that range (0-9
> inclusive) from being added into the quantity field regardless of
> constraints specified in custom forms.
>
> So the following custom form specific constraint:
>
> TR("Quantity:",INPUT(_type="text",_name="quantity",requires=IS_INT_IN_RANGE
> (1,100))),
>
> would only further limit the constraint specified by the model. If
> this were the case, it wouldn't make sense to allow values in the
> custom form that the model did not allow. For instance, a value of 50
> would pass the custom form validation, but get rejected by the model
> constraint. So the custom form constraint would effectively limit the
> values to 1-9 inclusive (10-99 would get rejected by the model
> constraint).
>
> I usually consider model definitions as hard rules for the data that
> should not be broken. But as Massimo stated, this is not the way it
> is implemented. It is too easy to be a critic when you aren't the one
> doing the implementation.
>
> Keep up the great work!
>
> On Mar 23, 12:39 pm, villas <[email protected]> wrote:
>
>
>
>
>
>
>
> > If I undertood correctly, you expect the model to have priority over
> > any other validation constraints.
>
> > This is not how it works in web2py. You may override validations at
> > any point and my experience is that it is very useful to do so.
>
> > If you wish to enforce a DB constraint which could not be overridden,
> > I suppose you might consider doing that in the DB itself.
>
> > On Mar 23, 3:45 pm, Jaunx <[email protected]> wrote:
>
> > > In Example 29 of the "Database Examples" of the Quick Examples
> > > tutorial, the last line of the model definition file (db.py) puts the
> > > following constraint on the purchases.quantity field:
>
> > > db.purchases.quantity.requires=IS_INT_IN_RANGE(0,10)
>
> > > In Example 33, the controller for the purchase form (forth line of the
> > > buy method in database_examples.py) defines the following constraint
> > > on the quantity:
>
> > > TR("Quantity:",INPUT(_type="text",_name="quantity",requires=IS_INT_IN_RANGE
> > > (1,100))),
>
> > > When you actually test the example application, the form accepts
> > > values between 1 and 99 inclusive and the database is updated with the
> > > appropriate value.
>
> > > What is the point of the constraint in the model definition if it is
> > > not enforced? Seems like the model would be the ideal place to set
> > > this constraint so that it doesn't need to be repeated for every form
> > > that uses it. However it would be nice to be able to override the
> > > default per form if necessary.
