[Erp5-dev] ZODB Components now in master

Vincent Pelletier vincent at nexedi.com
Mon Mar 12 10:38:19 CET 2012


Le Mon, 12 Mar 2012 11:58:36 +0900,
Arnaud Fontaine <arnaud.fontaine at nexedi.com> a écrit :
> [0]
> http://git.erp5.org/gitweb/erp5.git/commitdiff/4406c9b3ccf40861f34ea441299458071bbbfb9c
> [1]
> http://git.erp5.org/gitweb/erp5.git/commitdiff/2a7ab878059951e8c0a844d1ce1e1d0df31a1c5f

I'm unsure about the last hunk of first diff, first commit, and first
diff of second commit: so there is a global dict-ish holding script
source code, which gets flushed on script edition ?
But then, it's filled from transactional data. If the cache doesn't
take transactions into account, it can contain stale values. So we can
access some version of the script, but maybe not the one currently
committed it there was a timely change to that script.

Side note: in my understanding, the only grave bugs we can have when
moving code to ZODB are transactional/concurrency issues. They are
most certainly not covered by existing test suites (because no need
until now, and it's notoriously difficult to test). If this kind of bug
is not properly understood, and code is not carefully written to avoid
them, I am very scared of this new feature. I understand that "what
PDB/traceback display when an error is thrown" is not *so* critical,
but I have not reviewed other patches and hence fear to find the same
shortcomings there.

Also, reading linecache doc (as of 2.7), "cache" module property is not
documented. Can we really rely on it ? In my experience, undocumented
behaviours tend to be often broken in 2.7 (maybe to get closer to
python 3). We had at least 2 such breakages triggered in NEO by *minor*
python updates.
For the record, they came from:
- An invasive logger usage (logger name being dynamically computed),
  and upstream added an explicit type checking
- The mock module we use relied on a miss-implemented (ie,
  documentation states something that code doesn't follow) filter in
  inspect module. After my report, that change was rolled back, though
  (so code now behaves consistently with older implementations,
  although inconsistently with the spec).

-- 
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises



More information about the Erp5-dev mailing list