| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Refs #5109
|
|
|
|
|
|
4987 compliance check sets show
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
4824 create line referentials
|
|
|
|
enumerize for source_type_name, comments map display in stop_area form
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
