Re: auto_validations plugin: how to disable unique validations on all models
On Thu, Sep 2, 2021 at 6:30 AM 'petr@me.com' via sequel-talk < sequel-talk@googlegroups.com> wrote: > Hey Jeremy, > thank you for your answer. What do you think about this solution? > > Sequel::Model.plugin :subclasses do |sub_class| > sub_class.skip_auto_validations(:unique) > end > Sure, that should also work just fine. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CADGZSSe%3DR%2Bo42vzpHybw6W7P5LTpH8XQ%2BO2cV0Q0QcH14%2BAnjw%40mail.gmail.com.
Re: auto_validations plugin: how to disable unique validations on all models
Hey Jeremy, thank you for your answer. What do you think about this solution? Sequel::Model.plugin :subclasses do |sub_class| sub_class.skip_auto_validations(:unique) end Dne středa 1. září 2021 v 16:38:45 UTC+2 uživatel Jeremy Evans napsal: > On Wed, Sep 1, 2021 at 6:14 AM 'petr@me.com' via sequel-talk < > seque...@googlegroups.com> wrote: > >> Hi, >> how can I disable/skip unique auto validations on all models? >> >> I've tried Sequel::Model.skip_auto_validations(:unique) but it's not >> working... >> > > skip_auto_validations only affects the specific model you call it on, it > doesn't affect all subclasses. > > The simplest way is probably the following after loading the plugin: > > def (Sequel::Model).auto_validate_unique_columns > [] > end > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/986f6a5e-3f5f-4b52-aec2-9582d4a1a020n%40googlegroups.com.
Re: auto_validations plugin: how to disable unique validations on all models
On Wed, Sep 1, 2021 at 6:14 AM 'petr@me.com' via sequel-talk < sequel-talk@googlegroups.com> wrote: > Hi, > how can I disable/skip unique auto validations on all models? > > I've tried Sequel::Model.skip_auto_validations(:unique) but it's not > working... > skip_auto_validations only affects the specific model you call it on, it doesn't affect all subclasses. The simplest way is probably the following after loading the plugin: def (Sequel::Model).auto_validate_unique_columns [] end Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CADGZSSfX%2BNAmKeY_%2BpJFH%2B6V%3DWjvFzec3oY2YDi3A64PzS11gw%40mail.gmail.com.
auto_validations plugin: how to disable unique validations on all models
Hi, how can I disable/skip unique auto validations on all models? I've tried Sequel::Model.skip_auto_validations(:unique) but it's not working... -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/4feb8da6-4baa-490c-9e33-9fdea35eb008n%40googlegroups.com.
Re: Dropping a table does not drop all constraint validations
On Tuesday, March 12, 2019 at 2:08:01 PM UTC-5, Jeremy Evans wrote: > > Change committed: > https://github.com/jeremyevans/sequel/commit/d198cc1851c7cba380632a35f88ca193c346d6ae > Fantastic news. Thanks Jeremy! Mike -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Dropping a table does not drop all constraint validations
That fixed my problem. Long story short on the model name, I actually tried to rename from Auth_user to AuthUser at your suggestion and ran into the NameError so I changed it back and ran into the name error again! Setting the :class for each of the associations seems to have fixed this (I thought it had to do with caching since I was thorough about renaming (there was no code referencing the offending model name). I'll refactor this model when I have time later. Thanks again. Nic On Wed, Mar 6, 2019 at 11:02 AM Jeremy Evans wrote: > On Wednesday, March 6, 2019 at 10:42:21 AM UTC-8, Nick Appelmans wrote: >> >> I don't know if this is relevant or I should make a separate post for >> this topic but just in case it is: I renamed a model (AuthUser to >> Auth_user), dropped the table (authusers), recreated the table with the new >> model name (auth_users) and found that the old model name was still being >> referenced when Sequel was working out the associations. Here is part of >> the error message... >> > > It is certainly not related to Mike's issue with constraint validations. > > >> 2019-03-06 17:42:10 - NameError - uninitialized constant >> MemberTracker::AuthUser >> Did you mean? MemberTracker::Auth_user (this happened when attempting to >> find the associated class for >> #> MemberTracker::Log.many_to_one :auth_user, :key=>:a_user_id>): >> > > You probably need to change to: > > Log.many_to_one :auth_user, :class=>"MemberTracker::Auth_user", > :key=>:a_user_id > > It is kind of odd to change from AuthUser to Auth_user, though, as > AuthUser would be the typical name for the class. > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sequel-talk+unsubscr...@googlegroups.com. > To post to this group, send email to sequel-talk@googlegroups.com. > Visit this group at https://groups.google.com/group/sequel-talk. > For more options, visit https://groups.google.com/d/optout. > -- Nick Appelmans, Ph.D. (707) 834 6336 -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Dropping a table does not drop all constraint validations
On Wednesday, March 6, 2019 at 10:42:21 AM UTC-8, Nick Appelmans wrote: > > I don't know if this is relevant or I should make a separate post for this > topic but just in case it is: I renamed a model (AuthUser to Auth_user), > dropped the table (authusers), recreated the table with the new model name > (auth_users) and found that the old model name was still being referenced > when Sequel was working out the associations. Here is part of the error > message... > It is certainly not related to Mike's issue with constraint validations. > 2019-03-06 17:42:10 - NameError - uninitialized constant > MemberTracker::AuthUser > Did you mean? MemberTracker::Auth_user (this happened when attempting to > find the associated class for > # MemberTracker::Log.many_to_one :auth_user, :key=>:a_user_id>): > You probably need to change to: Log.many_to_one :auth_user, :class=>"MemberTracker::Auth_user", :key=>:a_user_id It is kind of odd to change from AuthUser to Auth_user, though, as AuthUser would be the typical name for the class. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Dropping a table does not drop all constraint validations
I don't know if this is relevant or I should make a separate post for this topic but just in case it is: I renamed a model (AuthUser to Auth_user), dropped the table (authusers), recreated the table with the new model name (auth_users) and found that the old model name was still being referenced when Sequel was working out the associations. Here is part of the error message... 2019-03-06 17:42:10 - NameError - uninitialized constant MemberTracker::AuthUser Did you mean? MemberTracker::Auth_user (this happened when attempting to find the associated class for #:a_user_id>): /app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in `constantize' /app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in `module_eval' /app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in `constantize' /app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/associations.rb:69:in `block in associated_class' /app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/associations.rb:563:in `block in cached_fetch' I tried to use :reload => true to clear the cache but I'm not using it correctly. I tried... aus = Auth_user.all aus.each do |au| au.logs(:reload => true) au.logs.each do |l| ... If this is an unrelated issue, I can repost this question which most likely has something to do with my misunderstanding of how to clear a cache. Thanks for any thoughts, Nick On Saturday, March 2, 2019 at 12:13:16 PM UTC-8, Jeremy Evans wrote: > > On Saturday, March 2, 2019 at 9:58:16 AM UTC-8, Mike Pastore wrote: >> >> Jeremy, >> >> Just to confirm something. It appears that dropping the table :foo does >> not also drop all constraint validations for table :foo. So my down >> migrations should all look like this: >> >> down do >> drop_table(:foo) >> drop_constraint_validations_for(:table=>:foo) >> end >> >> In order to prevent the sequel_constraint_validations table from becoming >> "cluttered." Or am I missing something? >> >> This is particular relevant if you later recreate the table with >> similar-but-slightly-different constraint validations. I had a case where I >> created a constraint validation with :allow_nil=>false, subsequently >> dropped the table, then later recreated the table and the same-named >> constraint validation but with :allow_nil=>true. This led to a situation >> where the former rule was still in effect when I expected the latter. >> >> I could also see a situation where defunct constraint validations persist >> in the sequel_constraint_validations table—for a dropped column, say—and >> get applied by the model plugin even though they are no longer valid. >> >> It would be nice if dropping a table or a column automatically removed >> applicable constraint validations, if that's even possible. Just a wishful >> thought. >> > > It is expected that currently you have to drop the constraint validations > manually. However, I think it makes sense to drop them automatically, and > it should still be backwards compatible (the > drop_constraint_validations_for call should be idempotent). If you would > like to work on a PR for the constraint_validations extension, that would > probably speed up the process, but I'll try to get to it sometime in the > next few releases. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Dropping a table does not drop all constraint validations
On Saturday, March 2, 2019 at 9:58:16 AM UTC-8, Mike Pastore wrote: > > Jeremy, > > Just to confirm something. It appears that dropping the table :foo does > not also drop all constraint validations for table :foo. So my down > migrations should all look like this: > > down do > drop_table(:foo) > drop_constraint_validations_for(:table=>:foo) > end > > In order to prevent the sequel_constraint_validations table from becoming > "cluttered." Or am I missing something? > > This is particular relevant if you later recreate the table with > similar-but-slightly-different constraint validations. I had a case where I > created a constraint validation with :allow_nil=>false, subsequently > dropped the table, then later recreated the table and the same-named > constraint validation but with :allow_nil=>true. This led to a situation > where the former rule was still in effect when I expected the latter. > > I could also see a situation where defunct constraint validations persist > in the sequel_constraint_validations table—for a dropped column, say—and > get applied by the model plugin even though they are no longer valid. > > It would be nice if dropping a table or a column automatically removed > applicable constraint validations, if that's even possible. Just a wishful > thought. > It is expected that currently you have to drop the constraint validations manually. However, I think it makes sense to drop them automatically, and it should still be backwards compatible (the drop_constraint_validations_for call should be idempotent). If you would like to work on a PR for the constraint_validations extension, that would probably speed up the process, but I'll try to get to it sometime in the next few releases. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Sequel throwing an error when validations fail
On Sunday, December 2, 2018 at 2:55:00 PM UTC-8, Steven Garcia wrote: > > Coming from ActiveRecord I was a bit perplexed by Sequel's behavior when > validations fail. > > In a Rails app I could simply run a condition on @model.valid? and keep it > moving. > > But Sequel actually throws an error, which breaks the app - so I find > myself doing this: > > begin @site.update(r.params[:site]) > flash.now[:done] = 'Update complete' > rescue Sequel::ValidationFailed > flash.now[:fail] = 'Woops! Something went wrong.' > end > > Which 100% works, but feels a bit clunky to me. > I usually abstract this to a method called handle_validation_failure(template_to_render, flash_error_message). Sequel is designed to raise exceptions for save failures by default, as it makes it so you must explicitly handle failures. By just returning false for save failures (ActiveRecord's behavior), it's fairly easy to silently ignore a failure. As you've seen, you can get that behavior if you want it. In apps I've converted from ActiveRecord to Sequel, I've used raise_on_save_failure = false temporarily for an easier conversion, then turned it back on, and often found cases where the code wasn't actually handling the failure and was treating the failure like success. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Sequel throwing an error when validations fail
Nevermind - figured it out: Sequel::Model.raise_on_save_failure = false Just starting to get the hang of your API ;) Cheers -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Sequel throwing an error when validations fail
Coming from ActiveRecord I was a bit perplexed by Sequel's behavior when validations fail. In a Rails app I could simply run a condition on @model.valid? and keep it moving. But Sequel actually throws an error, which breaks the app - so I find myself doing this: begin @site.update(r.params[:site]) flash.now[:done] = 'Update complete' rescue Sequel::ValidationFailed flash.now[:fail] = 'Woops! Something went wrong.' end Which 100% works, but feels a bit clunky to me. Am I going about this the right way? Is there some hidden config/setting that I can tweak to change this behavior? -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Validations: allow errors.add before valid?
I wanted to do validations outside of the model (so outside of `Sequel::Model#validate`), and then I also found out that #valid? first clears the errors. For me it worked that instead of `#valid?` I just used `errors.empty?`, and it worked great for my case. If you do want to have validations in your model, and you don't have any *_validation hooks, you could override #valid? to suit your needs: class Sequel::Model def valid? validate errors.empty? end end What's great about Sequel that unlike ActiveRecord it uses instance methods, and it's very clear what they do, so it's very easy to peek at the source code and override things. On Friday, June 5, 2015 at 11:46:54 PM UTC+2, James wrote: This is sort of a feature request I guess, and something that's caused me to bang my head a few times now. Currently you can access #errors and #errors.add methods on a model, but they're not of any use (that I'm aware of). Any errors added using errors.add() prior to calling valid? will be discarded when you call valid?. It would be much more intuitive to be able to add errors to a model prior to calling valid?, and have them cause valid? to return false. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Validations: allow errors.add before valid?
Thank you, that's a simple solution. On Thursday, July 2, 2015 at 5:06:22 AM UTC-6, Janko Marohnić wrote: I wanted to do validations outside of the model (so outside of `Sequel::Model#validate`), and then I also found out that #valid? first clears the errors. For me it worked that instead of `#valid?` I just used `errors.empty?`, and it worked great for my case. If you do want to have validations in your model, and you don't have any *_validation hooks, you could override #valid? to suit your needs: class Sequel::Model def valid? validate errors.empty? end end What's great about Sequel that unlike ActiveRecord it uses instance methods, and it's very clear what they do, so it's very easy to peek at the source code and override things. On Friday, June 5, 2015 at 11:46:54 PM UTC+2, James wrote: This is sort of a feature request I guess, and something that's caused me to bang my head a few times now. Currently you can access #errors and #errors.add methods on a model, but they're not of any use (that I'm aware of). Any errors added using errors.add() prior to calling valid? will be discarded when you call valid?. It would be much more intuitive to be able to add errors to a model prior to calling valid?, and have them cause valid? to return false. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Validations: allow errors.add before valid?
This is sort of a feature request I guess, and something that's caused me to bang my head a few times now. Currently you can access #errors and #errors.add methods on a model, but they're not of any use (that I'm aware of). Any errors added using errors.add() prior to calling valid? will be discarded when you call valid?. It would be much more intuitive to be able to add errors to a model prior to calling valid?, and have them cause valid? to return false. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Validations: allow errors.add before valid?
A quick example using irb: irb(main):002:0 o = Order.last irb(main):003:0 o.valid? = true irb(main):004:0 o.errors.add(nil, 'Test') = [Test] irb(main):005:0 o.valid? = true irb(main):006:0 On Friday, June 5, 2015 at 3:46:54 PM UTC-6, James wrote: This is sort of a feature request I guess, and something that's caused me to bang my head a few times now. Currently you can access #errors and #errors.add methods on a model, but they're not of any use (that I'm aware of). Any errors added using errors.add() prior to calling valid? will be discarded when you call valid?. It would be much more intuitive to be able to add errors to a model prior to calling valid?, and have them cause valid? to return false. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Validations: allow errors.add before valid?
On Friday, June 5, 2015 at 2:46:54 PM UTC-7, James wrote:
This is sort of a feature request I guess, and something that's caused me
to bang my head a few times now. Currently you can access #errors and
#errors.add methods on a model, but they're not of any use (that I'm aware
of). Any errors added using errors.add() prior to calling valid? will be
discarded when you call valid?. It would be much more intuitive to be able
to add errors to a model prior to calling valid?, and have them cause
valid? to return false.
This behavior is by design:
o = Order.last
o.valid? #= false
o.errors # = {name=is not present}
o.name = 'Foo'
o.valid? # = true
If you really want to make sure a model will be considered invalid when
saved, use the instance_hooks plugin:
Order.plugin :instance_hooks
o = Order.last
o.before_validation_hook{o.errors.add(nil, 'Test')}
o.valid? # = false
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
Transactions are not rollback if save fails because of validations and raise_on_save_failure is false
These are the models : class User Sequel::Model self.raise_on_save_failure = false end class Addresses Sequel::Model many_to_one: user self.raise_on_save_failure = false end address = Addresses.find(id: 1) user = address.user DB.transaction do address.delete user.save end In the above code if user.save returns nil as some validation fails the transaction is not rollback and that address is still deleted. Is it possible if user.save fails, address.delete is rollbacked where raise_on_save_failure = false. The transaction does rollback if raise_on_save_failure = true but dont want to set it true. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Transactions are not rollback if save fails because of validations and raise_on_save_failure is false
On Monday, March 31, 2014 7:39:01 PM UTC-7, Deepak Agrawal wrote: These are the models : class User Sequel::Model self.raise_on_save_failure = false end class Addresses Sequel::Model many_to_one: user self.raise_on_save_failure = false end address = Addresses.find(id: 1) user = address.user DB.transaction do address.delete user.save end In the above code if user.save returns nil as some validation fails the transaction is not rollback and that address is still deleted. Is it possible if user.save fails, address.delete is rollbacked where raise_on_save_failure = false. The transaction does rollback if raise_on_save_failure = true but dont want to set it true. This is expected behavior. If you want to explicitly rollback in save fails even if raise_on_save failure is false, you have two options. One is enabling exceptions for that particular save: DB.transaction do address.delete user.save(:raise_on_failure=true) end The second is explicitly rolling back if you detect a save failure: DB.transaction do address.delete raise Sequel::Rollback unless user.save end Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To post to this group, send email to sequel-talk@googlegroups.com. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
Re: Feedback Request: Constraint Validations
Jeremy, I've long wanted something like this because I believe the database should hold the constraint rules and often prefer to just define the database constraints and and be lazy with the model validation declarations. After all, if the database is enforcing a solid set of data integrity rules, as DBMS's have gotten quite good at doing, why trust ruby validations to the job (esp. when they can't prevent scripting mistakes made outside the application's code-base like the database constraints can)? So this is something I'm definitely interested in and will try to take a good look at in the next week or so to provide feedback. Michael On Tue, Aug 28, 2012 at 11:34 AM, Jeremy Evans jeremyeva...@gmail.com wrote: On Tuesday, August 28, 2012 12:35:11 AM UTC-7, Jamie Hodge wrote: Hi Jeremy, First of all, thank you. I'm really happy that you've unified validations and constraints. I found their separation to be a source of bugs and confusion. I've moved a small project over to the current version of the extension/plugin and have three short comments. If you look at the snippet below, you'll see that I've purposely left some redundant elements in the column and validation/constraint specification: String :name, null: false citext :url, null: false, unique: true ... validate do presence [:name, :url] max_length 255, [:name, :url] ... unique :url end I believe this is not an issue, but my question is if it would be clearer to extend the behaviour of the existing column options (i.e. null and unique), once the extension is loaded. Many of the column types also include implicit size constraints, which could possibly be inferred. I purposely chose require constraint validations to be explicit. It is possible to use some implicit information as you mentioned, but it raises additional questions: When do you add to the metadata table? Do you check every time for the existence of the metadata table, and automatically add them if the metadata table is present? Do you only add them if there is a validate block inside the create_table/alter_table? What if you just want the constraint without the validation (for speed reasons), what do you do? My second comment is a nice to have, which would be to include basic numerical checks, i.e. an integer field is greater than 0. I'm open to adding additional types of constraint validations in the future. I started just mirroring the validations in validation_helpers, and there isn't an existing validation for greater than/less than (though there is one for max/min length. Note that if you have an upper bound, you can use includes with a range of integers. In order for additional constraint validations to be supported, the underlying validations have to be supported by validation_helpers, since that is what the constraint_validations plugin uses internally. Lastly, and I'm not even sure if this is good practice, I tend to add validates_presence against association accessors (i.e. thing, not thing_id), with the purpose of avoiding having the DB raise reference errors. Would it be possible to use the existing foreign_key helper to generate minimal does-this-reference-exist checks in the application? Theoretically, you could. But that requires doing stuff implicitly. Also, there isn't a way to map between foreign key names and association names when creating/altering tables (since associations are a model thing and schema modification is a database thing), so even if you wanted to do that, you'd have to add the association name as an option to the foreign_key call. Once again, thank you! I've even noticed a speed-up during testing. Good to hear. Thanks for taking the time to submit feedback. Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/Plaq2bDdrIsJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en. -- http://codeconnoisseur.org -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
Hi Jeremy, First of all, thank you. I'm really happy that you've unified validations and constraints. I found their separation to be a source of bugs and confusion. I've moved a small project over to the current version of the extension/plugin and have three short comments. If you look at the snippet below, you'll see that I've purposely left some redundant elements in the column and validation/constraint specification: String :name, null: false citext :url, null: false, unique: true ... validate do presence [:name, :url] max_length 255, [:name, :url] ... unique :url end I *believe* this is not an issue, but my question is if it would be clearer to extend the behaviour of the existing column options (i.e. null and unique), once the extension is loaded. Many of the column types also include implicit size constraints, which could possibly be inferred. My second comment is a nice to have, which would be to include basic numerical checks, i.e. an integer field is greater than 0. Lastly, and I'm not even sure if this is good practice, I tend to add validates_presence against association accessors (i.e. thing, not thing_id), with the purpose of avoiding having the DB raise reference errors. Would it be possible to use the existing foreign_key helper to generate minimal does-this-reference-exist checks in the application? Once again, thank you! I've even noticed a speed-up during testing. Regards, Jamie Hodge -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/U2vrBffJxk0J. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On Thursday, August 9, 2012 2:35:22 PM UTC-7, Jeremy Evans wrote: On Wednesday, August 1, 2012 12:38:15 PM UTC-7, Jeremy Evans wrote: In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. I haven't received much feedback on this, so I would still appreciate additional review/comments. I didn't get much feedback, but what I did get was positive (thanks you Christian and Iain). I don't want to leave the branch out there any longer, plus I have other related work, so I've rebased the consvals branch onto master and merged it. I'm still open to making significant changes to it before 3.39 is released in a couple weeks, so I would still appreciate additional feedback. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/dDpti3B0jYAJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
Le 2012-08-14 à 02:07, Christian MICHON a écrit :
Hi Jeremy,
On Sun, Aug 12, 2012 at 2:39 PM, Christian MICHON
christian.mic...@gmail.com wrote:
One problem though: using this code, my saved Human object 'Bobby'
gets its id = 2, because 1st save did not work: is this the expected
behavior?
On PostgreSQL, sequences are not subject to transaction commit/rollback. This
is to prevent race conditions. Notice the following:
# create sequence myseq; select nextval('myseq'); begin; select
nextval('myseq'); rollback; select nextval('myseq');
CREATE SEQUENCE
nextval
-
1
(1 row)
BEGIN
nextval
-
2
(1 row)
ROLLBACK
nextval
-
3
(1 row)
After the ROLLBACK, the next value is 3, instead of 2 if the rollback had
happened.
I suspect the same thing happens on H2: Sequel runs INSERT INTO humans(...)
VALUES (...), which requests the next value for the sequence, and since
sequences aren't rolled back, then the next value after that has the gap.
Hope that helps!
François Beausoleil
--
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com.
To unsubscribe from this group, send email to
sequel-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
Hi Jeremy, On Sun, Aug 12, 2012 at 2:39 PM, Christian MICHON christian.mic...@gmail.com wrote: On Thu, Aug 9, 2012 at 11:35 PM, Jeremy Evans jeremyeva...@gmail.com wrote: On Wednesday, August 1, 2012 12:38:15 PM UTC-7, Jeremy Evans wrote: In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. This sounds cool. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. I haven't received much feedback on this, so I would still appreciate additional review/comments. I just tried on H2 database. I did not think the backend SQL would hold the constraint, as this seemed too good to be true, but it works out of the box as advertised. I did the following, and manage to check saved validations using H2 without Sequel: require 'sequel' DB=Sequel.connect 'jdbc:h2:test' DB.extension(:constraint_validations) DB.create_constraint_validations_table DB.create_table(:humans) do primary_key :id String :name validate do presence :id min_length 5, :name end end class Human Sequel::Model(DB[:humans]) end o = Human.new o.name = 'Bob' o.save o.name = 'Bobby' o.save One problem though: using this code, my saved Human object 'Bobby' gets its id = 2, because 1st save did not work: is this the expected behavior? -- Christian -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On Monday, August 13, 2012 11:07:52 PM UTC-7, Christian MICHON wrote: One problem though: using this code, my saved Human object 'Bobby' gets its id = 2, because 1st save did not work: is this the expected behavior? The reason you get id 2 is that it actually tries to do the insert for the first save. That's because you didn't use the constraint_validations plugin in the Human model (you only used the Database extension). If you use the model plugin, the validation code should see the name Bob as invalid and should not attempt the insert. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/NcfC8Fhmb-0J. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On Tue, Aug 14, 2012 at 5:13 PM, Jeremy Evans jeremyeva...@gmail.com wrote: On Monday, August 13, 2012 11:07:52 PM UTC-7, Christian MICHON wrote: One problem though: using this code, my saved Human object 'Bobby' gets its id = 2, because 1st save did not work: is this the expected behavior? The reason you get id 2 is that it actually tries to do the insert for the first save. That's because you didn't use the constraint_validations plugin in the Human model (you only used the Database extension). If you use the model plugin, the validation code should see the name Bob as invalid and should not attempt the insert. My bad: I should have realized I only triggered the extension and not the plugin. From a personal point of view, this looks like a very good feature :-) -- Christian -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On Thu, Aug 9, 2012 at 11:35 PM, Jeremy Evans jeremyeva...@gmail.com wrote: On Wednesday, August 1, 2012 12:38:15 PM UTC-7, Jeremy Evans wrote: In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. I haven't received much feedback on this, so I would still appreciate additional review/comments. Thanks, Jeremy Keep in mind it's still summer holidays, so not many people might have checked it yet. I will test it tomorrow on jruby and H2 database. -- Christian -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On Wednesday, August 1, 2012 12:38:15 PM UTC-7, Jeremy Evans wrote: In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. I haven't received much feedback on this, so I would still appreciate additional review/comments. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/i1MO677G7zgJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Feedback Request: Constraint Validations
On 1 Aug 2012, at 20:38, Jeremy Evans wrote: In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. Thanks, Jeremy It sounds like a good idea to me, I had a quick look at the source and the docs seem to make sense too. I've a project I can use it on in the next few days so I'll let you know if I have any trouble. Thanks. Regards, Iain -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Feedback Request: Constraint Validations
In a fairly unusual step for Sequel, I have pushed another public branch to GitHub, named consvals. From the commit message: The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered. I've thought about doing this for a long time, but only recently figured out a good way to implement this. Usually, I would just merge something like this into the master branch, but as the extension creates its own table, it will be quite a pain to modify the schema for the table later. To avoid potential problems in the future, I would like to get some feedback about this branch before I merge it. I plan on leaving this branch publicly available for one week for feedback. After I week, I'll decide whether to merge it as-is, merge it with changes, or not merge it at all, depending on the feedback received. If you have any feelings about this one way or the other, please make them known. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/DfmKO9mliWYJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Case insensitivity and unique validations.
On Saturday, July 7, 2012 5:25:31 PM UTC-6, cult hero wrote: I've been looking for the best way to deal with that amounts to a case insensitive column in PostgreSQL. (It stores email addresses.) I've found a couple of options (an index using lower() and triggers using lower()) but is there some way to make validates_unique do so in an insensitive manner? That way is n...@example.com is entered, n...@example.com will still anger the validation gods. Or do I need to make my own validation for this? Use citext to store the email address. http://www.postgresql.org/docs/9.1/static/citext.html -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/tNYmC_yC-zgJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Case insensitivity and unique validations.
I've been looking for the best way to deal with that amounts to a case insensitive column in PostgreSQL. (It stores email addresses.) I've found a couple of options (an index using lower() and triggers using lower()) but is there some way to make validates_unique do so in an insensitive manner? That way is n...@example.com is entered, n...@example.com will still anger the validation gods. Or do I need to make my own validation for this? -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/tziAZ_DzrF4J. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: nested_attributes and validations on the parent model
That makes sense. I'm going with the flag route, since I'd like to keep the validation together and not create one in a before_save block. Thanks Jeremy. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/1wEKGM868tUJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: nested_attributes and validations on the parent model
Also, I created a gist to test this out. It contains the original problem and an fix implementation using a flag for conditional validation. Maybe someone will find this useful if they run into the same problem. https://gist.github.com/3014816 -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/vJJF-pHYnm4J. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
nested_attributes and validations on the parent model
I have a parent model, Product, that has many Variants. I'm using nested_attributes on the Product model. On the Variants model I have a presence validation on the :product. When I try to persist the product with some :variants_attributes, I get a validation error saying: gems/sequel-3.36.1/lib/sequel/model/base.rb:1228:in `save': variants product is not present (Sequel::ValidationFailed) If I remove that validation, the product_id gets set correctly in the Variant table. Do I have to manually set the product_id somewhere so that the validation can pass? It seems like the id is set on save, so the validation fails because valid? is called before save. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/wm3Ueg8CO7IJ. To post to this group, send email to sequel-talk@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: nested_attributes and validations on the parent model
On Thursday, June 28, 2012 5:06:11 PM UTC-7, Jack wrote:
I have a parent model, Product, that has many Variants. I'm using
nested_attributes on the Product model. On the Variants model I have a
presence validation on the :product. When I try to persist the product with
some :variants_attributes, I get a validation error saying:
gems/sequel-3.36.1/lib/sequel/model/base.rb:1228:in `save': variants
product is not present (Sequel::ValidationFailed)
If I remove that validation, the product_id gets set correctly in the
Variant table. Do I have to manually set the product_id somewhere so that
the validation can pass? It seems like the id is set on save, so the
validation fails because valid? is called before save.
Here's the probable order of events:
1) Product and Variants get validated
2) Product gets saved
3) Variants get saved
You are getting the error because the nested_attributes plugin does the
validation of the associated objects at the same time it validates the
current object, which is before saving the current object. This is by
design so that validation errors in associated objects prevent saving of
the current object.
In the case of a new Product, the product's id will not be available until
after saving, so it's not like you could cheat and assign the keys earlier
in that case. You probably need to either remove that validation from
Variant (or move the check into a before_save hook), or make it conditional
and set some flag that disables it when it is being created via
nested_attributes, i.e.:
def variants_attributes=(vs)
super
associations[:variants].each{|v| v.check_product = false}
end
Jeremy
--
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/oTotSMC8g68J.
To post to this group, send email to sequel-talk@googlegroups.com.
To unsubscribe from this group, send email to
sequel-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
Re: Validations in Rails 3
The only methods Rails form's error_messages is calling from a model's error object are #count and #full_messages, which, like Jeremy said, are there already in Sequel::Model. Works fine in my project. The only thing i tried to use that was in AR, but not in Sequel was the Error#add_to_base method. no big deal. On Mar 24, 3:28 pm, Jeremy Evans jeremyeva...@gmail.com wrote: On Mar 24, 12:21 pm, cult hero binarypala...@gmail.com wrote: These are valid points. I guess in that case, I need to figure out how to get Sequel validations to work in line like AM's would for things like forms and such. I'm trying to avoid reinventing the wheel as much as possible. Can the Sequel validations be used with the Rails form helper without a lot of special plumbing? (Or does the the AM plugin handle this?) I remember there being an option so that validations don't throw an exception somewhere. Is that all I need to enable here? ActiveModel's only requirement is that errors responds to full_messages, which Sequel's does regularly, even without the active_model plugin. Theoretically, this should allow it to work correctly in Rails. However, I'm not sure that Sequel::Model::Errors is perfectly API compatible with what AR uses, I haven't really looked. You probably want: Sequel::Model.raise_on_save_failure = false Without that, Sequel will raise an exception if you attempt to save an invalid object. With that, save will just return false instead of raising an exception, similar to how AR handles things. Jeremy -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-t...@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Validations in Rails 3
In my previous project I had my own validations system that had carried over as a legacy component. I want to dump that in favor of something in wider use. My question is this: Should I use Sequel's validations or include ActiveModel's in a new project. I'm guessing AM's integrates better with Rails at large (locales and the like), and if I remember correctly Sequel validations are simply application level too, so it's not like they're any different as far as the data goes. With that said, if AM's would be the preference, any idea how to get them up and running? include ActiveModel::Validations in my model doesn't seem to work. Something simple like: validates_presence_of :first_name, :last_name Still seems to be calling the Sequel validations. -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-t...@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Re: Validations in Rails 3
Personally, I would use Sequel's. The Rails API seems to change often on a whim while Sequel breaks backwards compatibility on much rarer occasions. Plus, if implemented right, you can invest your business logic in your models and maintain easy portability to other systems. Right now, I have one folder I keep my model definitions in coupled with a heavy dose of specs to keep them well-tested and these model files don't depend on Rails, Ramaze, or any other framework. I am using these same model classes in three different Ramaze-based apps, several cronjob and rake-only ETL (extract, transform, load) tasks as well as beanstalkd job processing. Just something to think about. Rails, Ramaze, Sinatra, etc. look like they come and go with fairly rapid turnover/evolution, while the data access layer seems to remain a bit more stable and long-lived, so for me, a deliberate and conscious design decision was made to invest in keeping the models well-structured, encapsulated, and well-covered via specs so that I may be free to choose any of the other tools I need to get a job done. Michael -- http://ramblings.gibberishcode.net -- You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-t...@googlegroups.com. To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
Something I've always wished for: validations before any arbitrary model method
So this isn't really supported by other ORM's and I can't find a match in the Sequel rdoc for validations, so it's probably not supported. But maybe there's a way to accomplish this. One thing I've always wanted is class-level validation hooks that can specify an arbitrary method name to run the validation :on. For example some pseudo-AR-code: class UserCreation AR::Base validates_presence_of :page, :on = [:search, :list] validates_presence_of :per_page, :on = [:search, :list] validates_presence_of :search_string, :on = :search end Then: UserCreation.list(params[:list]) UserCreation.search(params[:search]) Now, I know in Sequel you can just do this via instance methods/etc. The reason class methods have alot of value for my app is we do alot of reflection on our XML/JSON services side to basically self-document our API (eg, we generate a RelaxNG structure that shows params, request method, response structure, etc). So this way we can say UserCreation.validations_for(:search).each.etc.etc (Currently we have a custom plugin for AR that we run locally to accomplish this.) Thoughts? If similar functionality already exists in Sequel, great, otherwise Jeremy are you open to me extending the validation_class_methods plugin to accomplish this? class MyClass Sequel::Model validates :on = [:search, :list] do numericality_of :page numericality_of :per_page end validates :on = :search do length_of :search_string end end I can also monkey-patch locally, I just like to feed stuff back when I can. -Nate --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~--~~~~--~~--~--~---
Re: Something I've always wished for: validations before any arbitrary model method
On Oct 15, 7:44 pm, Nate Wiger nwi...@gmail.com wrote: So this isn't really supported by other ORM's and I can't find a match in the Sequel rdoc for validations, so it's probably not supported. But maybe there's a way to accomplish this. One thing I've always wanted is class-level validation hooks that can specify an arbitrary method name to run the validation :on. For example some pseudo-AR-code: class UserCreation AR::Base validates_presence_of :page, :on = [:search, :list] validates_presence_of :per_page, :on = [:search, :list] validates_presence_of :search_string, :on = :search end Then: UserCreation.list(params[:list]) UserCreation.search(params[:search]) You could do this with a model plugin. In ClassMethods in the plugin, add the validation methods you want. Have the validation methods add a module included in the class (if it doesn't already exist), and add the methods to the module (call super unless things are invalid). There are some other plugins that do similar things, see the lazy_attributes plugin for an example. Now, I know in Sequel you can just do this via instance methods/etc. The reason class methods have alot of value for my app is we do alot of reflection on our XML/JSON services side to basically self-document our API (eg, we generate a RelaxNG structure that shows params, request method, response structure, etc). So this way we can say UserCreation.validations_for(:search).each.etc.etc (Currently we have a custom plugin for AR that we run locally to accomplish this.) Thoughts? If similar functionality already exists in Sequel, great, otherwise Jeremy are you open to me extending the validation_class_methods plugin to accomplish this? class MyClass Sequel::Model validates :on = [:search, :list] do numericality_of :page numericality_of :per_page end validates :on = :search do length_of :search_string end end I can also monkey-patch locally, I just like to feed stuff back when I can. I think this would be best as a separate plugin, since it operates very differently from the validation_class_methods plugin (which just overrides the validate method). I'm not sure of the general utility of this approach (though I'm sure it works well for your app), so I don't think it should be shipped with Sequel. I'm not completely opposed to shipping it with Sequel, but I'd need some positive feedback from multiple members of the community before making that decision. However, if you create any open source Sequel plugins that you want to share, please send me a link and I'll include it in the plugins page. External plugin usage is no different from internal plugin usage from a user perspective, the only advantage to the internal plugins is that I test them with the current code before pushing to github. Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com To unsubscribe from this group, send email to sequel-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~--~~~~--~~--~--~---
questions about validations
Is there an :if option available with validations? I am trying to reproduce the restful_authentication plugin to work with sequel and using something like this. attr_accessor :password validates_presence_of :password, :if = :password_required? protected def password_required? self.crypted_password.blank? || !self.password.blank? end I'm assuming that I need to do this another way as its not working, should I write my own validates_each or is there an easier way to do this? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: questions about validations
Ok, thanks. I'll give not_naughty a shot! Funny name :) On May 26, 11:28 am, Jeremy Evans [EMAIL PROTECTED] wrote: On May 26, 8:20 am, dusty [EMAIL PROTECTED] wrote: Is there an :if option available with validations? I am trying to reproduce the restful_authentication plugin to work with sequel and using something like this. attr_accessor :password validates_presence_of :password, :if = :password_required? protected def password_required? self.crypted_password.blank? || !self.password.blank? end I'm assuming that I need to do this another way as its not working, should I write my own validates_each or is there an easier way to do this? I believe the not_naughty plugin can do this, but there isn't an option to do it with the default validations in Sequel. Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: questions about validations
On May 26, 8:20 am, dusty [EMAIL PROTECTED] wrote: Is there an :if option available with validations? I am trying to reproduce the restful_authentication plugin to work with sequel and using something like this. attr_accessor :password validates_presence_of :password, :if = :password_required? protected def password_required? self.crypted_password.blank? || !self.password.blank? end I'm assuming that I need to do this another way as its not working, should I write my own validates_each or is there an easier way to do this? I believe the not_naughty plugin can do this, but there isn't an option to do it with the default validations in Sequel. Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Validations and create_before
What's the suggested way to specify a 'validates_presence_of :attr' validation where 'attr' is set in the before_create block? save returns false and says that 'attr' is not set save! works, no exceptions thrown, but I would prefer to use save. Farrel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Validations and create_before
On May 8, 11:33 am, Farrel [EMAIL PROTECTED] wrote:
What's the suggested way to specify a 'validates_presence_of :attr'
validation where 'attr' is set in the before_create block?
save returns false and says that 'attr' is not set
save! works, no exceptions thrown, but I would prefer to use save.
Farrel
As a follow on has the the behaviour of save! changed in Sequel 1.5.1?
In the following spec tests:
1: @organisation.save.should( be_false )
2: lambda{ @organisation.save! }.should( raise_error( PGError, /
uuid/ ))
the spec on line 1 passes as @organisations is invalid, however line 2
fails as no exception is raised!
Farrel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Validations and create_before
On May 8, 5:03 am, Farrel [EMAIL PROTECTED] wrote:
On May 8, 11:33 am, Farrel [EMAIL PROTECTED] wrote:
What's the suggested way to specify a 'validates_presence_of :attr'
validation where 'attr' is set in the before_create block?
save returns false and says that 'attr' is not set
save! works, no exceptions thrown, but I would prefer to use save.
The master branch has before_validation and after_validation hooks
that should fix this issue.
As a follow on has the the behaviour of save! changed in Sequel 1.5.1?
In the following spec tests:
1: @organisation.save.should( be_false )
2: lambda{ @organisation.save! }.should( raise_error( PGError, /
uuid/ ))
the spec on line 1 passes as @organisations is invalid, however line 2
fails as no exception is raised!
Line 2 is only going to raise an error if the database itself raises
an error when inserting/updating the record. Also, changes are going
in today that will change the error raised from a database specific
error (such as PGError), to Sequel::Error, at least for MySQL,
PostgreSQL, and SQLite.
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Validations
I can't actually find it. SourceForge or did you mean RubyForge where
I can't find the patch either... :/
Am 18.04.2008 um 23:10 schrieb Uzytkownik:
On Apr 17, 8:39 am, Florian Aßmann [EMAIL PROTECTED] wrote:
Hi Uzytknownik,
If you provide attribute names on builder invokation you only need
to write:
validates(:name) { uniqueness }
this only make sense if you validate this attribute in different
ways.
Let me guess, you want to have scope support... uhm... I think I
can get my
hands on this the coming weekend.
I've actually posted some patch to not_naughty sf.net page some time
ago along with a ticket.
Regards
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Validations
May I ask is it possible to use conditional validation in new Sequel? I cannot find it neighter working nor in assistance documentation (I can in validatable documentation, which sequel seems to use no more). Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Validations
You can try the not_naughty plugin for validations: http://groups.google.com/group/sequel-talk/browse_frm/thread/7ca5e048f427e829/978bfc9b8b71b82d?hl=enlnk=gstq=not_naughty#978bfc9b8b71b82d On Apr 14, 9:50 am, Uzytkownik [EMAIL PROTECTED] wrote: May I ask is it possible to use conditional validation in new Sequel? I cannot find it neighter working nor in assistance documentation (I can in validatable documentation, which sequel seems to use no more). Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Validations
On Apr 14, 6:53 pm, Aman Gupta [EMAIL PROTECTED] wrote: You can try the not_naughty plugin for validations: http://groups.google.com/group/sequel-talk/browse_frm/thread/7ca5e048... Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: validations using assistance 0.1.4
great!! =) is there any place that i can log future bugs? thanks! On Feb 16, 4:02 pm, Sharon Rosner [EMAIL PROTECTED] wrote: In my model, I tried to put each in the validates block, but this would generate errors on running spec. However, if I place the each clause outside the validates block, my spec would be able to run. This was a bug in the assistance gem. I pushed out a new release so it should be available in a few hours. best Sharon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: validations using assistance 0.1.4
This was a bug in the assistance gem. I pushed out a new release so it
should be available in a few hours.
Would this also fix my poblem?
The following code using ADO fails.
db = Sequel.ado 'db_name', :user = 'sa', :password =
'some_pwd', :host = 'my_computer_name'
sql = 'select top 1 * from table'
db[sql].each {|r| p r}
This causes the following error.
d:/ruby/lib/ruby/gems/1.8/gems/sequel_core-1.0.10/lib/sequel_core/
adapters/ado.rb:26:in `method_missing': Open (WIN32OLERuntimeError)
OLE error code:80004005 in Microsoft OLE DB Provider for ODBC
Drivers
[Microsoft][ODBC Driver Manager] Data source name not found and
no default driver specified
HRESULT error code:0x80020009
Exception occurred. from d:/ruby/lib/ruby/gems/1.8/gems/
sequel_core-1.0.10/lib/sequel_core/adapters/ado.rb:26:in `connect'
from d:/ruby/lib/ruby/gems/1.8/gems/sequel_core-1.0.10/lib/
sequel_core/database.rb:27:in `initialize'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:108:in `call'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:108:in `make_new'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:100:in `available'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:91:in `acquire'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:90:in `synchronize'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:90:in `acquire'
from d:/ruby/lib/ruby/gems/1.8/gems/assistance-0.1.4/lib/assistance/
connection_pool.rb:57:in `hold'
from d:/ruby/lib/ruby/gems/1.8/gems/sequel_core-1.0.10/lib/
sequel_core/database.rb:150:in `synchronize'
from d:/ruby/lib/ruby/gems/1.8/gems/sequel_core-1.0.10/lib/
sequel_core/adapters/ado.rb:57:in `fetch_rows'
from d:/ruby/lib/ruby/gems/1.8/gems/sequel_core-1.0.10/lib/
sequel_core/dataset.rb:174:in `each'
from D:/Source/ruby/engine/test/sequel_test.rb:20
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: new validations implementation
After some further thought I'm rewriting the whole thing again and will also build an errors class. you'll probably see a solution later today. Sharon, Two things that would be great to see as you rewrite validations are: 1) Make update(...) check for validations like save(...) 2) obj.errors.on(:col) returns an empty array currently if there are no errors. This is ok but I think returning nil would be nicer and would make sequel models play well with form helpers built into merb. Best, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: new validations implementation
def errorify_field(attrs, col) attrs.add_html_class!(error) if @_obj.respond_to?(:errors) @_obj.errors.on(col) end After some further thought I'm rewriting the whole thing again and will also build an errors class. you'll probably see a solution later today. best sharon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: new validations implementation
After some further thought I'm rewriting the whole thing again and will also build an errors class. you'll probably see a solution later today. Sharon, I look forward to the new version! Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: new validations implementation
On Jan 16, 2008 4:16 AM, Sharon Rosner [EMAIL PROTECTED] wrote: hi everybody the new validations implementation is in the trunk, so please give it a whirl. i've tried to follow the validation specs as implemented in ActiveRecord, rather than the validatable gem which is incomplete and even wrong in a couple places. There are some things missing, like a smarter #errors (right now it's just a simple array of error messages), and some of the validations are missing a few options. Right now Model#save returns false and doesn't save if validations fail. There's a new Model#save! method that saves regardless of validations. Also missing is ability to inherit validations in subclasses, but that will come real soon. Sharon, Good stuff! I took a look around the new validations and things look pretty tight. Of course like you say the big things that are missing are being able to query to the validity of a particular attribute. This could be done by making the errors array into a smarter object like in AR. I know this is a requirement for code out there like merb's form helpers which die after querying for model attribute status like: def errorify_field(attrs, col) attrs.add_html_class!(error) if @_obj.respond_to?(:errors) @_obj.errors.on(col) end Of course the last comparison will fail in Sequel as Array doesn't have an on(...) method... Looking forward to the last phases of the validation refactoring and overall I'm really liking Sequel! Best, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
I would see the sequel-model class having a base set of validations that are all performed on the code side. Then each database plugin can somehow override this base set to provide validation from the database. This would allow people to switch between databases without any changes to their code. As for if that is even possible with sequels current design I have no idea, I have yet to look very far into the code base. Not to mention some may not want to use the DB constraints so how would you deal with them? You also bring up something I was not thinking about, how do you specify DB based constraints without causing problems when moving from one DB to another. Not to mention keeping you migrations straight with your current model. It seems to me that the constraints need to be somehow defined model side to keep all that model logic in one place. Meh, I don't have a good idea on how to solve that one. -Jeremy On Jan 15, 3:28 am, Chris Farmiloe [EMAIL PROTECTED] wrote: The capabilities of each database system vary so much here that I can't see it ever being a truly portable solution like the rest of Sequel. maybe if database specific plugins were created that could upgrade the validations with DB specific reinforcements. ie. a sequel_postgres_constraints plugin would be nice to have a little more of the database power in our models... special filters to define triggers for instance. But handling these as plugins is the only way I think. /just thinking aloud On 15/01/2008, David Lee [EMAIL PROTECTED] wrote: Hey Jeremy, Thanks for responding. I was also thinking about validations that cannot be done database side. Perhaps we can have different terminology for the two types of validations. The currently popular AR style validates_xxx can remain in their current functionality, and database side validations errors can be caught in a different way: database_validates_uniqueness_of :name # database_validates_format_of :email database_validates_length_of :x database_validates_presence_of :age database_validates_reference_to :posts database_validates_constraint /boo/, :msg = Oh no! ... The last line above can match any error that contains boo and is a useful construct because constraints can be named in the database side. The second to last line would catch errors caused from foreign-key errors. How does this sound? -- Chris Farmiloe web:www.oxdi.eu direct: 01273 782909 skype: chrisfarms --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
I'm curious about what seems to be a current state of saving a model with validations. Right now it seems that obj.save will save the object to the database regardless of whether or not it passes validations. I would like to know if this is the intended behavior. Right now it is the intended behavior. I'm going to dive in today and rewrite the vaidations code. My suggestion is to have #save check for validity, and also have a #save! method which bypasses validations. I think that's a reasonable solution, and if I'n not mistaken that's how things are done in Og. sharon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
Errors are, as you say, database-specific. However, we already do have database specific code, so it won't be causing any portability issues that were not there in the first place. That said, perhaps the simplest way of getting this started is to implement the database_validates_constraint method and have everything else work off of that. This seems like a good overall abstraction layer to work on top of, unless the database also sends back an integer error code. If the database layer does send back an integer error code, then we could also support an :error_code option. database_validates_length_of, database_validates_presence_of, and database_validates_reference_to can be implemented by the database_validates_constraint. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
You also bring up something I was not thinking about, how do you
specify DB based constraints without causing problems when moving from
one DB to another. Not to mention keeping you migrations straight with
your current model. It seems to me that the constraints need to be
somehow defined model side to keep all that model logic in one place.
Meh, I don't have a good idea on how to solve that one.
I think validations should be separate from constraints. Those are
really two different things with different capabilities. I really
don't see the connection between them, and IMO there's no chance of
implementing something like that will work decently. Too coupled, too
complicated.
On the other hand, it would be good to have a way to add constraints
when creating or altering a table. Maybe something like:
DB.create_table :items do
...
constraint {:price 0}
constraint :valid_discount {:discounted_price :price}
end
DB.add_constraint :valid_discount {:discounted_price :price}
I think that should satisfy those who need validations in the
database.
sharon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
Hey Jeremy, On Jan 15, 8:28 am, jrmy [EMAIL PROTECTED] wrote: I would see the sequel-model class having a base set of validations that are all performed on the code side. Then each database plugin can I agree. There are certain validations that can only be performed client side. However, there are also validations that can only be performed database side. This is the problem we face. somehow override this base set to provide validation from the database. This would allow people to switch between databases without any changes to their code. As for if that is even possible with I don't think we should have the database_validates_xxx overwrite validates_xxx because the behavior and the expectations are different. The database_validates_xxx validations, for one, are guaranteed validations. sequels current design I have no idea, I have yet to look very far into the code base. Not to mention some may not want to use the DB constraints so how would you deal with them? We would want to keep the database_validates_xxx separate from validates_xxx precisely because some users prefer one over the other. You also bring up something I was not thinking about, how do you specify DB based constraints without causing problems when moving from one DB to another. Not to mention keeping you migrations straight with your current model. It seems to me that the constraints need to be somehow defined model side to keep all that model logic in one place. Meh, I don't have a good idea on how to solve that one. I agree with what Chris suggested on this one: separate the constraint code into each database adapter. -Jeremy Perhaps the term validations is not very fitting, although I like it. Maybe constraints are just better terms for the database side things. Maybe instead of database_validates_xxx we should say database_constrains_xxx. We could be more precise and call it depends_on_database_to_constrain_rows_based_on, but that would be silly. :) --David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
On Jan 15, 2008 8:38 AM, Sharon Rosner [EMAIL PROTECTED] wrote: I'm curious about what seems to be a current state of saving a model with validations. Right now it seems that obj.save will save the object to the database regardless of whether or not it passes validations. I would like to know if this is the intended behavior. Right now it is the intended behavior. I'm going to dive in today and rewrite the vaidations code. My suggestion is to have #save check for validity, and also have a #save! method which bypasses validations. I think that's a reasonable solution, and if I'n not mistaken that's how things are done in Og. +1 on having #save check validations and abort on failure. Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
On Jan 15, 2008 8:48 AM, Sharon Rosner [EMAIL PROTECTED] wrote:
You also bring up something I was not thinking about, how do you
specify DB based constraints without causing problems when moving from
one DB to another. Not to mention keeping you migrations straight with
your current model. It seems to me that the constraints need to be
somehow defined model side to keep all that model logic in one place.
Meh, I don't have a good idea on how to solve that one.
I think validations should be separate from constraints. Those are
really two different things with different capabilities. I really
don't see the connection between them, and IMO there's no chance of
implementing something like that will work decently. Too coupled, too
complicated.
On the other hand, it would be good to have a way to add constraints
when creating or altering a table. Maybe something like:
DB.create_table :items do
...
constraint {:price 0}
constraint :valid_discount {:discounted_price :price}
end
DB.add_constraint :valid_discount {:discounted_price :price}
I think that should satisfy those who need validations in the
database.
Yes - IMO these should be separate.
This way you can do a quick validates_uniqueness_of in model code to
catch 99.999% of the cases which is sufficient for many apps. If you
really want to garentee uniqueness you can add a constraint as well.
Zack
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
Once again,
I'm not saying we should support constraints WITHIN the model.
Let me state my assumptions:
- validations exist to give users a nice error message to prevent
models from being saved, because otherwise, the database will raise a
nasty error
- validations do not validate 100%
- constraints validate 100%
- constraints cannot be defined in model, they must be defined when
defining tables
- preventing from within Ruby code rollbacks from database both have
same results -- NO CHANGE.
- constraints raise ugly exceptions
- validations give nice error messages
So I'm suggesting that we should have a feature for models to RESCUE
(catch) the exception raised by the database connection and turn it
into a nice error message, like what validations do.
database_validates_constraint would not tell the database to actually
implement the constraint (because that's done when defining tables)
but would CATCH a constraint error thrown by the database and
translate that into a nice error message, like what validations do.
Example:
# table definition
DB.create_table :items do
...
constraint price_is_positive {:price 0}
...
end
# model
database_validates_constraint 'price_is_positive', :msg = Price
must be positive!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
Wow, I didn't mean to uncork a can of worms on this one, I hope it got
as sorted out as it appears to be.
If I understand this correctly, I can expect to see a .save .save!
methods appear in sequel_model, as well as changes to the validations
so that some validations are done based on the model, and some (like
uniqueness) are done based on the database's response.
Or is it more likely that I misread something and the validations are
going to start being based on the constraints the database is
performing, so that a save will attempt to update the database, which
will then throw the errors back to sequel_model and then let us end-
users deal with the sequel_model error?
I'm curious about this, as I don't have control over the database
designs for every database I have to interact with, and I certainly
can't vouch for the knowledge of those developers to leverage the
database appropriately.
-Joe
On Jan 15, 2:39 pm, jrmy [EMAIL PROTECTED] wrote:
Now I understand what you are wanting. I agree with the others that it
should be separated.
-Jeremy
On Jan 15, 11:53 am, David Lee [EMAIL PROTECTED] wrote:
Once again,
I'm not saying we should support constraints WITHIN the model.
Let me state my assumptions:
- validations exist to give users a nice error message to prevent
models from being saved, because otherwise, the database will raise a
nasty error
- validations do not validate 100%
- constraints validate 100%
- constraints cannot be defined in model, they must be defined when
defining tables
- preventing from within Ruby code rollbacks from database both have
same results -- NO CHANGE.
- constraints raise ugly exceptions
- validations give nice error messages
So I'm suggesting that we should have a feature for models to RESCUE
(catch) the exception raised by the database connection and turn it
into a nice error message, like what validations do.
database_validates_constraint would not tell the database to actually
implement the constraint (because that's done when defining tables)
but would CATCH a constraint error thrown by the database and
translate that into a nice error message, like what validations do.
Example:
# table definition
DB.create_table :items do
...
constraint price_is_positive {:price 0}
...
end
# model
database_validates_constraint 'price_is_positive', :msg = Price
must be positive!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
I'm going to look at validations soon and do some refactoring. I will also look into this problem. You could instead of saving, check for errors before saving. however it seems more ideal for the object to keep track of its own state in this case. -Lance On Jan 14, 2008 5:59 PM, Joe [EMAIL PROTECTED] wrote: Hi, I'm curious about what seems to be a current state of saving a model with validations. Right now it seems that obj.save will save the object to the database regardless of whether or not it passes validations. I would like to know if this is the intended behavior. If it is the intended behavior, I'd like to try and sway the maintainers to change the behavior, as it's better to have unsaved data and an error message, than invalid saved data. I understand if it's simply that the validations are new, and no one wanted to make passing the validations a requirement for saving yet, but it seems goofy to me to have validations and not require them to be met in order to save the data. Sorry if this has come up in discussion before (and if it seems I'm just stirring the pot), but I did not see anything about this in recent posts. (eg, since the validations seemed to have been added in the first place.) -Joe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model validations saving
I wish validations were tightly integrated into the database. Validations are something that ActiveRecord was not good at. For example, validating uniqueness or presence of an associated object would actually not enforce validation (under rare race conditions). This is because it is impossible for Ruby to do constraints for databases. The proper way to validate would be to add constraints into the database itself. Thus, I propose that we have a constraint-error-parsing validation system. All validations would be defined in the migrations as constraints, and the validation system would check for error messages AFTER the database call. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model Validations
I'm not exactly sure what you are trying to accomplish. there is a validates_uniqueness_of :column also I believe you can group validations.. though we should pretty this syntax up. Look how this is accomplished using the validatable gem. This is subject to change in the future. Perhaps a combo of the state machine and validations might be the answer, we're still working these things out. -Lance On Jan 3, 2008 4:52 AM, David Lee [EMAIL PROTECTED] wrote: Hi, Is there a way to incorporate constraints + checks in validations? Like a way for Sequel to parse constraint errors returned from a statement and return an error message accordingly... It might be better not to call it validations but maybe check_for(column, constraint) or something so that you can call: check_for :item_id, :unique and Sequel would safely return instead of raising an error. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Sequel::Model Validations
Some subtle design refactorings:
we should change validations validates so the block looks like this:
validates do
format_of :name, etc.
presence_of :name
end
Also validations is a class method in validatable :). Wayne and I are
refactoring right now.
Also a :with_options hash might be nice.. so you could do:
validates :with_options = { :if = Proc.new { !name.nil? }} do
etc.
end
Although ^^ that looks a bit messy. Any suggestions?
-Lance Carlson
On Dec 22, 2007 1:37 PM, Wayne E. Seguin [EMAIL PROTECTED] wrote:
Friends,
Lance Carlson and I have been working on on adding model validations.
Please review the current API and provide us with some feedback and
suggestions.
Thank you!
~Wayne
=Basic Sequel Validations
Sequel validations are based on the Validatable gem
http://validatable.rubyforge.org/
To assign default validations to a sequel model:
class MyModel SequelModel(:items)
validations do
format_of...
presence_of...
acceptance_of...
confirmation_of...
length_of...
true_for...
numericality_of...
format_of...
validates_base...
validates_each...
end
end
You may also perform the usual 'longhand' way to assign default model
validations
directly within the model class itself:
class MyModel SequelModel(:items)
validates_format_of...
validates_presence_of...
validates_acceptance_of...
validates_confirmation_of...
validates_length_of...
validates_true_for...
validates_numericality_of...
validates_format_of...
validates_base...
validates_each...
end
Each validation allows for arguments:
TODO: fill the argument options in here
=Advanced Sequel Validations
TODO: verify that advanced validations work as stated (aka write specs)
NOTE: experimental
To store validations for conditional usage simply specify a name with which
to store them
class User Sequel::Model
# This set of validations becomes stored as :default and gets injected
into the model.
validations do
# standard validations calls
end
validations(:registration) do
# user registration specific validations
end
validations(:promotion) do
# user promotion validations
end
end
To use the above validations:
@user.valid ?# Runs the default validations only.
@user.valid?(:registration) # Runs both default and registration
validations
@user.valid?(:promotion)# Runs both default and promotion validations
You may determine whether the model has validations via:
validations? # will return true / false based on existence of validations
on the model.
You may also retrieve the validations block if needed:
validations(:registration) # returns the registration validation block.
validations() method parameters:
a validations block - runs the validations block on the model stores as
:default
a name and a validations block - stores the block under the name
a name - returns a stored block of that name or nil
nothing - returns true / false based on if validations exist for the
model.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
