| Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We now always use modules for namespaces
=> same structure for models, decorators, policies...
|
|
|
|
|
|
objectid_support handles reading and writing object_ids
objectid_formater_support gets the right formater class
include these concerns in chouette models
Remove StifNetexAttributSupport modules because these are handled by the new objectid concerns
Add a objectid and formater classes for each format type
Add objectid formats to the factories
Modify somes specs for object_ids but there are still a number of failling tests
|
|
|
|
|
|
remove the Chouette namespace
off of the construction of link in the app and in other places.
Added a small change in the reflex sync to set the stop_area_referential in the initialization of the object to be in sync with the work on the objectids (need a objectid_formatter)
|
|
We now always use modules for namespaces
=> same structure for models, decorators, policies...
|
|
class names on several models
|
|
|
|
|
|
Luc discovered this error in my method that destroys associated
non-ready `Referential`s:
> WorkbenchImport.destroy_all
WorkbenchImport Load (3.0ms) SELECT "public"."imports".* FROM "public"."imports" WHERE "public"."imports"."type" IN ('WorkbenchImport')
(1.5ms) BEGIN
ImportMessage Load (2.7ms) SELECT "public"."import_messages".* FROM "public"."import_messages" WHERE "public"."import_messages"."import_id" = $1 [["import_id", 58]]
ImportResource Load (1.9ms) SELECT "public"."import_resources".* FROM "public"."import_resources" WHERE "public"."import_resources"."import_id" = $1 [["import_id", 58]]
Import Load (0.3ms) SELECT "public"."imports".* FROM "public"."imports" WHERE "public"."imports"."parent_id" = $1 [["parent_id", 58]]
ImportMessage Load (0.5ms) SELECT "public"."import_messages".* FROM "public"."import_messages" WHERE "public"."import_messages"."import_id" = $1 [["import_id", 59]]
ImportResource Load (4.8ms) SELECT "public"."import_resources".* FROM "public"."import_resources" WHERE "public"."import_resources"."import_id" = $1 [["import_id", 59]]
SQL (1.3ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 636]]
SQL (0.3ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 635]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 634]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 633]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 632]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 631]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 630]]
SQL (0.1ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 629]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 628]]
SQL (0.1ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 627]]
SQL (0.1ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 626]]
SQL (0.3ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 625]]
SQL (0.3ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 624]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 623]]
SQL (0.2ms) DELETE FROM "public"."import_resources" WHERE "public"."import_resources"."id" = $1 [["id", 622]]
Import Load (0.3ms) SELECT "public"."imports".* FROM "public"."imports" WHERE "public"."imports"."parent_id" = $1 [["parent_id", 59]]
Referential Load (0.6ms) SELECT "public"."referentials".* FROM "public"."referentials" WHERE "public"."referentials"."id" = $1 LIMIT 1 [["id", 18]]
(0.2ms) ROLLBACK
NoMethodError: undefined method `ready' for nil:NilClass
from .../stif-boiv/app/models/netex_import.rb:20:in `destroy_non_ready_referential'
Since `referential` is not a required attribute, it can be nil. That was
causing this to break because I tried to destroy a `Referential` that
doesn't exist. Check that there's an associated `Referential` before
trying to destroy it.
Refs #4991
|
|
4823 compliance check show
|
|
|
|
path does not work anymore
|
|
|
|
|
|
|
|
- I18n.t explicit in helper so that it can be used in specs.
- Typo in spec db setup fixed and setup of blocks put into create
instead of later update.
|
|
|
|
- Implements the view
Missing:
- Spex failing (xpath navigation inside the display blocks is still faulty)
- Links to compliance_checks#show do not work (actually not this page's problem)
|
|
[skip-ci]
|
|
after_commit on: :create
|
|
- using webmock instead of mocking Net::HTTP
therefore removing the connascence between the spec and the
HTTP lib used in the implementation, thank you Teddy
|
|
|
|
|