| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
Convert the hash syntax in `models/referential.rb` to new Ruby hash
syntax.
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
|
|
Refs #5024
|
|
Refs #5024
|
|
Make it clear in the code (not just in the commit message) that this
callback must go last.
Refs #5024
|
|
It was possible for two identical referentials (with the same metadata)
to be created and persisted if they were created at the same time. This
is validated by the test: `spec/models/referential_spec.rb:164`.
As a heavy-handed solution to that problem, prevent two referentials
from being created at the same time by setting a lock on the
`referentials` database table before Rails validation begins. This
prevents any other referentials from being saved at the same time as the
current one. Thanks to Alban for coming up with the lock Postgres query.
The lock should be the last `before_validation` hook that gets executed,
so we put it after the other `before_validation` definitions. We want it
to be the last one because we're trying to hold the lock for as little
time as possible.
Note that we don't need to explicitly unlock the table as this will
happen automatically at the end of the transaction.
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
|
|
Rename the method to `build_referential`. Saw it because my project grep
didn't work.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#4735
|
|
|
|
Refs #5074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
stif_netex
|
|
|
|
|
