- 06 Aug, 2019 1 commit
-
-
Georges Racinet authored
Anyblok 0.22 and SQLAlchemy < 1.3
-
- 05 Aug, 2019 2 commits
-
-
Georges Racinet authored
This is now shipping with AnyBlok 0.22 (unittest-style tests with nose are deprecated, but that's a different question). Still reexporting to avoid fixing all our internal uses
-
Georges Racinet authored
Since it's been added, the compatibility of AnyBlok with SQLAlchemy 1.3 has been fixed (in AnyBlok 0.21.0) and SQLAlchemy 1.3 has become the minimal AnyBlok supported version AWB tests seem to fail on AnyBlok 0.21.0, so let's jump straight to 0.22.0
-
- 09 Mar, 2019 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
Made a single method on `Action` to mutate `op_fields` in place. Applications can act on all fields, and must be careful not to create inconsistencies.
-
Georges Racinet authored
We have a Travis build failure (should be probably reported / fixed against AnyBlok) that can be reproduced by installing SQLAlchemy 1.3. Temporary avoiding that version for the time this is fixed
-
- 08 Mar, 2019 1 commit
-
-
Georges Racinet authored
Inventory: new `considered_types` attribute
-
- 25 Feb, 2019 1 commit
-
-
Georges Racinet authored
Up to now `exclude_types` and `considered_types` where used to filter `PhysObj` instances only, meaning that in the case where an Inventory would have lines about irrelevant Types, it would have given improper results. One could argue that such lines shouldn't arise in the first place, but the possibility exists that `exclude_types` or `considered_types` could be changed after the fact. At least, we keep a consistent behaviour in that case, even though applications probably should not allow them to happen.
-
- 21 Feb, 2019 3 commits
-
-
Georges Racinet authored
This allows to issue Inventories that consider only certain Physobj.Type, potentially across the whole system.
-
Georges Racinet authored
This must have been a new error in pep8, I had to upgrade mine to reproduce.
-
Georges Racinet authored
This branch has lingered a bit too long, and is actually used in some installations. Best to merge it and proceed from there. Some minor adaptations in test harness: run_all_tests, registering in test_partial, and the use of UTC instead of FixedOffsetTimezone had to be done in the merge
-
- 29 Nov, 2018 7 commits
-
-
Georges Racinet authored
PyPy support
-
Georges Racinet authored
-
Georges Racinet authored
Since anyblok_createdb doesn't work on all drivers, we avoid it in favour of a psql call. See also https://github.com/AnyBlok/AnyBlok/issues/74
-
Georges Racinet authored
- test_partial.py now has an option for alternate driver, defaulting to the appropriate one for PyPy if needed - run_all_tests.py no more depends on psycopg2 and passes either psycopg2 or psycopg2cffi driver name to actual test scripts. Also sandboxes all Python executables to be the virtualenv's
-
Georges Racinet authored
Now, on PyPy, the requirement of psycopg2 is changed to the cffi version. This is good enough for now, but I've seen erratic behaviour after installing with pip -e from the same code base in two different virtualenvs (PyPy and CPython), don't do that.
-
Georges Racinet authored
Apparently, Trusty is still the default, but it doesn't support Python >= 3.7 (see warning at the end of https://docs.travis-ci.com/user/languages/python/#specifying-python-versions)
-
Georges Racinet authored
I'm personnaly developing or using AWB with Python 3.5 (current Debian stable, stretch) to 3.7 (current Python stable) and I'm also involved on a project using 3.6. We don't need 3.6-dev anymore, but 3.8-dev could be of interest
-
- 28 Nov, 2018 1 commit
-
-
Georges Racinet authored
It was only lazyness on my part to use these timezones in tests (same as seen coming back from psycopg2). It's much simpler to use datetime.timezone.utc
-
- 24 Nov, 2018 21 commits
-
-
Georges Racinet authored
All places where a ValueError was raised have now their meaningful exceptions.
-
Georges Racinet authored
Now disparitions and teleportations will choose in priority those physical objects that aren't reserved, and if forced to affect reserved ones, will take the most recent reservations first. This is also the first example of soft dependency in AWB, had to introduce a test skipping decorator (will upstream to AnyBlok)
-
Georges Racinet authored
This is a forward port of anyblok's counterpart See also https://github.com/AnyBlok/AnyBlok/pull/73
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It's a bit better for debugging purposes, in particular
-
Georges Racinet authored
This is a careless method that applies all Actions linked to the Inventory. It's not meant for production on large installations, but - it demonstrates how to apply linked Actions - it closes the loop so that wms-inventory can be used on development projects.
-
Georges Racinet authored
This condition obviously was already ensured by using the recursion but the recursion is to be thought as a default convenience for small installations.
-
Georges Racinet authored
This very simple implementation for `choose_affected()` closes the loop, but has to be enhanced to take various conditons (notably Reservations) into account.
-
Georges Racinet authored
All produced Operations are linked to the relevant Inventory, thanks to the newly introduced field on the mixin To create Disparitions and Teleportations, `Inventory.Action.apply()` relies on a common `choose_affected()` method, that's not yet written. It's mocked in the tests to check that, indeed, apply() does issue all three types of Inventory Operations correctly. This `choose_affected()` will be the place where trickier logic will stand, such as avoiding to affect reserved physical objects, etc. In particular, it'd be the main override target for dependent Bloks.
-
Georges Racinet authored
Besides factorizing the state checks, it should allow wms-inventory to override all Inventory Operations in one shot
-
Georges Racinet authored
no noqa marker is a bad thing, and thankfully has been useless in AWB for a while now
-
Georges Racinet authored
This is maybe playing too safe, but it addresses the concerns expressed in commit message 440b7c76c7b9ddec6a143e6b77bfa231c0dd0eb7 Indeed, there's a difference between limiting considered Lines to current Node and then doing the outer join (what we do now) and doing the outer join, then filtering out lines attached to other nodes (what we did). In the latter case, a phobj can match an unrelated Inventory Line, which then gets filtered out, resulting in no Action whereas in the correct case, this would lead to a missing Line, and should issue a disparition.
-
Georges Racinet authored
With this, we now have the possibility to resolve all needed actions for reconciliation on a whole Inventory. What remains at this point is: - to translate into Operations - to take Properties into account (also in computation) - to take Reservation into account (in the translation)
-
Georges Racinet authored
Forgot previously to restrict the Lines compared to existing PhysObjs and Avatars to those of the current Node! Since we only tried compute_actions() with only one None it didn't show up in tests before. As for the restriction itself, I also tried inside the join condition, but that doesn't work, mostly making it a left join (even with the OR IS NULL). I just hope the current query doesn't translate to PG as performing the full OUTER join for all existing lines, and only then restricting. That would be problematic for performance and even consistency.
-
Georges Racinet authored
That was a nice thing to forget previously
-
Georges Racinet authored
Still lacking the taking of Properties into account, we are now able to pair up apparitions and disparitions, somewhat in an arbitrary fashion. The idea behind this is that in some cases, this can lead to much less actions to be undertaken to reconcile the database with reality.
-
Georges Racinet authored
As the docstring of Inventory.excluded_types explains, this is mostly to exclude container types from Actions computation. This allows us to test an Action computation where the recursion of the query for physical objects is really useful and one where it's important not to recurse.
-
Georges Racinet authored
and this means that we can treat leaf Nodes and fully split Nodes only (ie those that have subnodes for each of their containers). To avoid any disaster, we explicitely forbid partially splitting Nodes.
-
Georges Racinet authored
and this allows us to reach the 100% mark (far from sufficient in this case, but that's a start)
-