toptal / database_validations Goto Github PK

Hey @djezzzl ! 👋

Cascade deletion is sometimes a very expensive operation.
In case the association is defined as dependent: :delete, it is possible to rely on the database to perform the deletion instead.
See :on_delete/:on_update.

Disclaimer: I clearly understand that dependent: :destroy should remain ignored, as destroy also runs callbacks.

Would it make sense to detect this and suggest changing the FK in such a way that the DB handles cascade deletion/nullification?

Sorry for not being verbose. I'd love to validate the idea with you first, and elaborate if you support it.

What do you think about opening some of the behavior here as a PR against ActiveRecord or whatever relevant Rails core gem? Being as relationships are foundational to models I would think they would welcome any performance & logical enhancements to them.

Hi, thank you for using our gem!

Here we have the list with opened tasks to do:

• Replace where option with conditions for validates_db_uniqueness_of so validates_db_uniqueness_of becomes easier replacement for validates_uniqueness_of.

• Add test coverage analyzer to CI and badge to README

• Foreign keys can accept NULL values, so we can support optional: true option for db_belongs_to

• Add support of Rails.application.config.active_record.belongs_to_required_by_default = false

• Matchers validates_presence_of and belong_to should work

You can also suggest a new feature! Any contribution is welcome!

Adding gem 'activerecord-postgis-adapter' to your Gemfile and configuring database.yml to use the postgis adapter:

default: &default
  adapter: postgis
  encoding: unicode
  ....

Will yield a system that is incompatible with database_validations, because the adapter name doesn't match, postgres.

Can you extend your supported adapters to also support postgres with the GIS extension?

Thanks!

While using db_belong_to with optional: true, it triggers a validation error prohibited this service from being saved.
Need to change db_belong_to to belong_to to associate with optional: true

db_belongs_to :company, optional: true
gives a validation error:
ActiveRecord::RecordInvalid: Validation failed: Company must exist
on empty value (company_id=nil), although
belongs_to :company, optional: true
in the same situation does not give an error

When using nested attributes the associated objects are autosaved, which either does a direct insert or saves with validate: false as you you can see here. This means when we get to the create_or_update defined in this gem here validate is false and the exceptions are not handled.

This is likely true of any collection associations that are autosaved, I only noticed it when using nested attributes though.

How do I configure the database to run specs for this project.

I recently upgraded from v0.9.0 to 1.0.1 in order to address the deprecation warnings for connection config. It has caused some of my tests to fail in a way that I wasn't expecting given the details outlined in the change log and I think it may be a bug.

I have a model called User which has many Questions. Questions must be unique by name for a given user. We have a controller for adding questions to a user which has a method along the lines of user.update(user_params_with_questions). The params include an array of questions to add.

In the failing test cases case we're attempting to add two new questions with the same name to a user as part of the same update operation. Previously, this returned false but it's now raising a RecordNotUnique error. If I add them sequentially I get the expected behaviour.

I went through a process of progressively upgrading from the original version to pinpoint when the breaking changes were introduced and found that 0.9.4 was the culprit. This is consistent with the stack trace which points to /lib/database_validations/lib/validations.rb:20:in create_or_update'`:

def create_or_update(*args, &block)
      options = args.extract_options!

      if options[:validate] == false
        super
      else
        rescue_from_database_exceptions { super }
      end
    end

So, my assumption is that something is causing the validate option to be interpreted as false and the super behaviour is being called vs the rescue_from_database_exceptions function.

Additional context:

Rails version: 6.1.4.1
Ruby version: 2.6.2

Any ideas about what might be going on here? Or additional behaviour that would help figure it out? Thanks in advance!

Hey,

How can I test on RSpec if validate_db_uniqueness_of is case_sensitive: true?

The matcher at https://github.com/toptal/database_validations/blob/master/lib/database_validations/rspec/uniqueness_validator_matcher.rb#L10 only has options for case insensitive.

Checking the diff from version 0.8.10 to latest master, the default for Rails 6 case_sensitive is nil.
v0.8.10...master#diff-0b72b6ffa59687cb5bb851b40f2ad87aR62
This causes all specs to fail if the validation is case_sensitive: true.

is this a limitation of the matcher? Are there plans to improve it?

Any help is appreciated.

Best Regards,
Ronaldo.

My first guess was something related to threads, then I tried to reproduce using Parallel gem, but I could not. I only get the expected behavior.

Any ideas on how can I debug this?