- 28 Sep, 2022 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 27 Sep, 2022 3 commits
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1621
-
Kazuhiko Shiozaki authored
-
Yusei Tahara authored
-
- 26 Sep, 2022 14 commits
-
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
- 23 Sep, 2022 4 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
- 22 Sep, 2022 2 commits
-
-
Jérome Perrin authored
It seems to accept int, but version is supposed to be a string.
-
Jérome Perrin authored
See merge request nexedi/erp5!1671
-
- 21 Sep, 2022 5 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
a modified version from $366 that supports patterns like DateTime(2001, 02, 03) => DateTime(2001, 2, 3) and not DateTime(2001, 0o2, 0o3)
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
- 20 Sep, 2022 2 commits
-
-
Jérome Perrin authored
Javascript does not support big integers, so the backend have to be careful not to return too large numbers in the json. Nowadays there is bigint, but not equivalent for decimal numbers, so the backend tries to detect if numbers are too big and returns them as string in that case - which is better than returning a different number because it displays correctly in the result table. The pivot table will still wrong, but at least the table of results is OK.
-
Jérome Perrin authored
-
- 16 Sep, 2022 3 commits
-
-
Jérome Perrin authored
use sax.xml API which gives us the first parser available, instead of using a specific parser that happens to come from pyxml
-
Jérome Perrin authored
serialize as json instead of using xml.marshal.generic which was provided by PyXML
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1668
-
- 15 Sep, 2022 5 commits
-
-
Jérome Perrin authored
See merge request nexedi/erp5!1665
-
Jérome Perrin authored
This allows custom movement generators to set ad-hoc properties on generated movements depending on properties of the corresponding input movement. There was already _getUpdatePropertyDict which is similar, but was sometimes not enough because it can only be use to set extra properties on all movements. As a result, when we needed a rule with custom properties on generated movements, we resorted to overriding getGeneratedMovementList and duplicating the full logic of the method. Existing cases have been updated to use the new _updateGeneratedMovementList and in the case of InventoryAssetPriceAccountingRuleMovementGenerator we no longer need to duplicate the logic. Also remove the comment suggesting overriding getGeneratedMovementList in subclasses, now several "extension" methods exists, so it should not be needed to override getGeneratedMovementList, every needs should be coverred by defining _updateGeneratedMovementList or _getUpdatePropertyDict
-
Jérome Perrin authored
This patch does not seem necessary
-
Jérome Perrin authored
-
Jérome Perrin authored
-
- 14 Sep, 2022 1 commit
-
-
Vincent Pelletier authored
This SELECT option was added when the UPDATE query was split into a SELECT + UPDATE query pair, in order to try to avoid deadlocks in mariadb. commit 7daaf0a5 Author: Vincent Pelletier <vincent@nexedi.com> Date: Fri Jun 7 16:53:11 2013 +0200 Work around poor UPDATE use of index. That was not completely successful, and another attempt was since made, which further ipmproved the situation: commit e21aa47f601a98f767e2d3e8490b20b7f409933c Author: Vincent Pelletier <vincent@nexedi.com> Date: Fri Sep 17 11:34:46 2021 +0900 CMFActivity.Activity.SQLBase: Reduce the number of deadlocks This change made the "FOR UPDATE" option obsolete: there should be virtually no parallelism between the SELECT and UPDATE queries. By which I mean only 3rd-party accesses (like an admin on a mysql console) would bypass the SQL lock, causing index-update-level locking issues. Checking now, I see that removing "FOR UPDATE" on the "node>0" query makes that query (with LIMIT 30) run about 5 times faster: With FOR UPDATE: 0.509s Without FOR UPDATE: 0.090s This difference is enough to cause significant activity starvation on a 63-processing-nodes cluster where such activities run in about 1s, just because of the amount of contention on the SQL lock, itself because of the duration of every execution of this query. So remove this now-redundant option. It is expected that this will improve activity processing performance in general, beyond just the starvation issue which led to this discovery.
-