20121114

Ich bin noch immer mit den Online-Demos dran, die demnächst fertig werrden müssten.

Eins

MultipleObjectsReturned: get() returned more than one City -- it returned 2! Lookup parameters were {'name': 'Eupen'}
INFO Lino initdb done ('std', 'all_countries', 'be', 'few_cities', 'all_languages', 'props', 'democfg', 'demo', 'demo_ev
ents') on database :memory:.

Oh, das war ein subtiler Bug! Es gab eine Fixture lino.modlib.accounting.fixtures.be, in dem fälschlicherweise keine Funktion objects definiert war.

Aber lino.utils.dumpy merkte das nicht, sondern rief stattdesen die objects der vorigen Fixture nochmal neu auf. Zumindest falls es denn der Zufall wollte, dass just zuvor eine Fixture mit dem gleichen Namen (hier “be”) geladen worden war. Das lag daran, dass ich imp.load_module falsch aufrief. Jetzt generiert er eindeutige temporäre Modulnamen im Stil “lino.utils.dumpy_tmp_37091808”.

When lino.Lino.build_js_cache_on_startup is None, lino.core.kernel now also considers DEBUG for finding the default value.

Zwei

Problem Nummer Zwei war besonders dumm und deshalb besonders schwer zu finden. Auf lf.org kam bei der initdb_demo von demo2 (presto) folgender Traceback:

Traceback (most recent call last):
  File "/home/luc/snapshots/django/django/core/management/commands/loaddata.py", line 221, in handle
    return
  File "/usr/lib/python2.6/contextlib.py", line 34, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/luc/snapshots/django/django/db/backends/__init__.py", line 271, in constraint_checks_disabled
    yield
  File "/home/luc/snapshots/django/django/core/management/commands/loaddata.py", line 190, in handle
    for obj in objects:
  File "/home/luc/mypy/demo2/using/lino/lino/utils/dumpy.py", line 497, in deserialize
    for obj in module.objects():
  File "/home/luc/mypy/demo2/using/lino/lino/modlib/users/fixtures/demo.py", line 55, in objects
    kw = root_kw(lang)
  File "/home/luc/mypy/demo2/using/lino/lino/modlib/users/fixtures/demo.py", line 23, in root_kw
    kw.update(profile=dd.UserProfiles.admin)
AttributeError: type object 'UserProfiles' has no attribute 'admin'

War auch wie folgt reproduzierbar. Erstelle eine Datei t.py mit folgendem Inhalt:

from django.conf import settings
settings.LINO.startup()

Starte die Datei:

$ python manage.py run t.py
INFO Starting Lino...
20120705 lino.UserProfiles.user:100(level=user,office=user)
20120705 lino.UserProfiles.admin:900(level=admin,office=admin)
INFO Analyzing models...
WARNING No help texts : no such table: lino_helptext
INFO Lino Site 'presto@armand' started. Languages: de, en, fr, et, nl. 197 actors.
INFO Using Lino Presto 0.0.1, Lino 1.5.1, Django 1.4.2, python-dateutil 1.5, Cheetah 2.4.4, OdfPy ODFPY/0.9.4, docutils
0.7, suds 0.4.1, PyYaml 3.08, Appy 0.8.0 (2011/12/15 22:41), Python 2.7.1, Silk Icons 1.3.

Auf lf.org fehlen in beiden Debug-Zeilen die name der UserProfiles:

20120705 lino.UserProfiles:100(level=user,office=user)
20120705 lino.UserProfiles:900(level=admin,office=admin)

Lösung war einfach, dass Mercurial mir einen Streich gespielt hatte: ich hatte nicht gemerkt, dass er eine lokal bearbeitete Datei nicht aktualisiert hatte.

Drei

Eine dritte Überraschung war die Erkenntnis, dass die meisten Aktionen par défaut nur für angemeldete Benutzer sichtbare sein sollten.