Well, the cause of the problem was that in my code the user model wasn't getting reloaded after failing validation, so my session user object would look like whatever the user put in the form until they logged back out and back in...
As for the rest of the explanation, it was very helpful! I very much appreciate you taking the time to write it. Just out of curiosity...why aren't raise_on_*_failure true by default if most web applications will want that? On Apr 13, 4:10 pm, Jeremy Evans <[email protected]> wrote: > On Apr 13, 3:47 pm, Max <[email protected]> wrote: > > > Hi all, > > > If I have a model called User, with some validation restrictions on > > it.... if I say user.update(a_hash) and the hash doesn't validate, an > > exception is raised, but the user record is also updated with the > > invalid hash. Can anyone explain why this happens or how I can avoid > > it? Preferably, I'd like to see two things: 1) be able to check if > > validation failed without involving exceptions, and 2) have data not > > be saved if an error occurs. > > > Using sqlite3 and the latest Sequel gems. > > You could be running into a few possible issues, which I'll discuss > below, but the best way to be sure is to include the code you are > using, preferably in a minimal self executing example that shows the > issue. That will greatly help debugging. > > Sequel::Model's behavior is configurable, but it is strict by default. > > By default, if your model is invalid (according to your validations), > Sequel will raise Sequel::ValidationFailed. You can set > raise_on_save_failure = false at a class or object level to change the > behavior. With raise_on_save_failure = false, save will return nil if > a validation fails. > > You could also be hitting a typecasting error, which will raise > Sequel::InvalidValue for bad typecast data. You can set > raise_on_typecast_failure = false to not raise an error when > typecasting data, but then you can have a string in an integer field. > > Also, if your hash is provided by the user and may have invalid keys > (keys which don't have a matching setter method in the model), the > Model#set code will raise a Sequel::Error. You can set > strict_param_setting = false to skip keys that don't have a matching > setter method, instead of raising an error. > > In it's default settings Sequel should not be sending a query to the > database inside a Model#update call unless the following things are > true: > > * All keys in the hash have valid setter methods > * All values in the hash typecast correctly > * The Model#validate call does not add any errors > > If this isn't the case for you, please let me know. If you aren't > sure of whether Sequel is actually updating a database, add an SQL > logger to the database to see what SQL Sequel is sending it. > > In general, most web applications are going to want to do the > following after requiring Sequel: > > Sequel::Model.raise_on_save_failure = false > Sequel::Model.raise_on_typecast_failure = false > > I don't generally recommend the use of strict_param_setting = false, > as it can hide bugs in your code. In a properly designed web > application, you shouldn't need it. > > Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
