Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Foreign Key checking even for belongs_to #31

Open
jhirbour opened this issue Dec 8, 2015 · 4 comments
Open

Foreign Key checking even for belongs_to #31

jhirbour opened this issue Dec 8, 2015 · 4 comments

Comments

@jhirbour
Copy link

jhirbour commented Dec 8, 2015

I'm not sure if this is a bug or a feature and I'm looking for some clarification.

I've got a rails model in our data warehouse that will record deletions of assignments. Because of this I've purposefully NOT added a FK constraint in PG.

Expectation: I expected schema_validations to just validate the presence of assignment_id instead of checking that the assignment_id is valid.

Actual: During execution the assignment row is deleted first and THEN I'm calling DataWarehouse::AssignmentDestroy.create() . The create fails with a validation that assignment can't be blank. From my testing it looks like it's actually testing that the assignment id is valid, NOT that is just exists.

Is this expected behavior?

  • Model
module DataWarehouse
  class AssignmentDestroy < DataWarehouse::Base
    belongs_to :assignment

    schema_validations
  end
end
  • Table
data_warehouse.assignment_destroys
                                          Table "data_warehouse.assignment_destroys"
    Column     |            Type             |                                    Modifiers
---------------+-----------------------------+---------------------------------------------------------------------------------
 id            | integer                     | not null default nextval('data_warehouse.assignment_destroys_id_seq'::regclass)
 created_at    | timestamp without time zone |
 updated_at    | timestamp without time zone |
 user_id       | integer                     | not null
 assignment_id | integer                     | not null
 comments      | text                        | not null
Indexes:
    "assignment_destroys_pkey" PRIMARY KEY, btree (id)
    "data_warehouse.assignment_destroys.assignment_id" btree (assignment_id)
    "data_warehouse.assignment_destroys.user_id" btree (user_id)
@ronen
Copy link
Member

ronen commented Dec 8, 2015

@jhirbour

The create fails with a validation that assignment can't be blank. From my testing it looks like it's actually testing that the assignment id is valid, NOT that is just exists.

That seems odd. schema_validations emits calls to rails' builtin validators, such asvalidates_presence_of; which i'd expect to work as advertised.

My suggestion is to start by grep'ing the log file for [schema_validations], which will tell you the exact rails validations that were generated. From there you can try to figure out which validation is causing the problem. It might be obvious by inspection that schema_validations is inserting a validation that you're not expecting (could even be a bug in schema_validations generating something it shouldn't i suppose).

But if the problem isn't obvious, then In fact I'd suggest temporarily copying the validations listed in the log file into your model and disabling schema_validations (you could do it via schema_validations auto_create: false in the model... or just remove schema_validations from your Gemfile). Then schema_validations will be out of the equation and the debugging process will be one step simpler.

@jhirbour
Copy link
Author

jhirbour commented Dec 9, 2015

Ok. I'll spin up a small test app (rather than our monolith) and test this out at a smaller scale. Make sure there's not something else in the mix. I'll let you know what I find.

@ronen
Copy link
Member

ronen commented Jan 19, 2016

@jhirbour any update on this? (Trying to tidy up the list of outstanding issues :) Thanks

@jhirbour
Copy link
Author

jhirbour commented Sep 1, 2021

Sorry I've switched jobs. Never got around to reproducing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants