| Age | Commit message (Collapse) | Author |
|---|
|
|
|
And fix a bug preventing the deletion of referentials without a schema
|
|
|
|
|
|
|
|
With according methods and scopes
|
|
|
|
|
|
5865 Ensure user is allowed to duplicate a referential
|
|
|
|
|
|
doing so
I also changed the way 403 errors are handled, to properly respond with
a 403 HTTP code
|
|
|
|
|
|
ReferentialSuite. Refs #5299
|
|
* Move these two tests to a new file to isolate them from the normal
Referential model tests
* Move the `workbench` to a `let`
* Remove unnecessary schema deletions in transactional synchronous test
* Add comments describing the lock mechanism and how we test it with
threads & sleeps
|
|
When creating `ReferentialMetadata`s, I had written in associations with
the `Referential`s built at the top of the tests. However, since those
referentials weren't saved and had no IDs, these "associations" had no
meaning. They can just be removed, and the association will be taken
care of by the `referential_#.metadatas <<` lines.
Thanks to Robert for pointing this out in pre-review.
Refs #5024
|
|
This `before` hook allows tests to use the "truncation" database cleanup
strategy. It doesn't do anything explicitly JavaScript-related. Rather,
it was named JS because it was intended to be used for feature tests
with JavaScript. However, now that I need to use it for a couple tests
in `spec/models/referential_spec.rb`, the `:js` name doesn't make sense.
Rename the filter to something that says what it does, not how it should
be used.
Refs #5024
|
|
Add an extra referential to the test and check that it gets saved to
confirm that the table lock gets released at the end of the transaction.
Not sure if this is actually necessary to verify, but wanted to make
sure before I had gone and read the Postgres docs
(https://www.postgresql.org/docs/9.4/static/explicit-locking.html#ADVISORY-LOCKS).
Refs #5024
|
|
This replicates the synchronous test and adds threads and sleeps to save
the two referentials asynchronously. This version fails, which is
consistent with the current behaviour of the application.
Refs #5024
|
|
Remove old commented code that no longer relates. The thread code will
be moved to a new test. This test now validates the existing behaviour
synchronously. Update the test descriptions accordingly.
Refs #5024
|
|
Change bits of the test to validate that when saving duplicate
`Referential`s synchronously, the second one fails to be saved.
A few things needed to be changed since the last commit in order to get
this test working:
* Most crucially: The `metadata_1.save` lines needed to be removed. The
metadata is indended to be saved at the same time as the
`Referential`s. Otherwise, the validation doesn't work the way it
should.
* `create` the workbench in order to be able to associate it
with the new referentials.
* Explicitly set the referential organisation to the workbench
organisation to pass validation that they both refer to the same
organisation.
* Explicitly make the `has_many` association of the metadata objects to
referentials.
* Since the second referential doesn't get saved when the spec passes,
no schema is created for it. Thus our previous `Apartment` `drop` call
failed for the second schema. To cover our bases for when the test
both fails and passes, check if the referentials were persisted as a
way of knowing whether the schema exists before trying to remove it.
Refs #5024
|
|
I removed the threads to try to test this synchronously. What should
happen is, the second referential should not be created. But it does get
created. So I'm thinking I made a mistake in setting up the data, and
the validation for 'same referentials' isn't run:
Failures:
1) Referential when two identical Referentials are created at the same time only creates one Referential
Failure/Error: expect(referential_2).not_to be_persisted
expected `#<Referential id: 3, name: "Test 1", slug: "test_1_different", created_at: "2017-11-28 15:41:04", upd...t: nil, created_from_id: nil, ready: true, referential_suite_id: nil, objectid_format: "stif_netex">.persisted?` to return false, got true
# ./spec/models/referential_spec.rb:174:in `block (3 levels) in <top (required)>'
# .../.gem/ruby/2.3.3/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:268:in `load'
# .../.gem/ruby/2.3.3/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:268:in `block in load'
# .../.gem/ruby/2.3.3/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
# .../.gem/ruby/2.3.3/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:268:in `load'
# .../.gem/ruby/2.3.3/gems/spring-commands-rspec-1.0.4/lib/spring/commands/rspec.rb:18:in `call'
# -e:1:in `<main>'
Finished in 8.46 seconds (files took 0.82295 seconds to load)
1 example, 1 failure
Just committing this to have it around since I spent a long time
fiddling with it. Next, planning to replace the factories with actual
imports to see if I can get the right result.
Edit: just realised that actually I can't try it with actual imports
because that's handled by Java.
Refs #5024
|
|
Here we formalise a bug whereby two "identical" `Referential`s are able
to be saved even though Rails validation would normally prevent this. It
can happen when two `Referential`s are functionally identical (but have
different `slug`s, as this would trigger a Postgres error).
In practise, this happens when multiple imports of the same data are
launched at similar times.
We'll want to make this test pass by not allowing the identical
`Referential` to be created. This will be accomplished as agreed with
the team by a database table lock.
The threads and sleeps (in particular) are unfortunate necessities
needed to get the two `Referential`s to be saved at the same time.
TODO: Need to check this again with the threads & sleeps turned off to
confirm that this passes in that case (actually it doesn't), so this
test needs some modification in order to be correct.
Refs #5024
|
|
This test was commented in October 2016, over a year ago
(6acac72115b2e575fb1698d74958356fe4d542f8). Seems like a good time to
get rid of it.
Refs #5024
|
|
|
|
|
|
Step 2: Added validation of reference->workbench->organisation consistency
Made all specs pass
Chased bug #4826
|
|
`ReferentialSuite` has many `Referential`s. Need to add a foreign key
column to the `referentials` table to allow that to work.
Refs #3519
|
|
regarding the functional scope of the current organozation
|
|
Refs #4132
|
|
passes current_organization down from the controller into Reference.new_from
adds joint models *ReferenceMemeberships to excluded Apartment models
|
|
Refs #2665
|
|
|
|
|
|
form). Refs #1782
|
|
|
|
|
|
Refs #1863
|
|
Refs #1863
|
|
|
|
Refs #1782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
