======================== Friday, October 16, 2015 ======================== Git cheat sheet =============== Hamza worked on :ticket:`505` and I merged his work on :ref:`cosi` and :ref:`welfare` to my masters. Note about how I do this. For each of our projects, Hamza made a fork to `his github account `__. I added his fork on my machine as a remote (for every project):: $ git remote add hamza https://github.com/HamZuS/XXX.git And now the most simple usage is to do the following (for every project):: $ git fetch hamza $ git merge hamza/master Testing #505 ============ I tried Hamza's changes on the test environment in Eupen. It turned out that they *do* have duplicate accounts. At least for the moment. A duplicate :class:`Account ` object currently exists if two clients have a common account at the bank. Of course this is not correct (and I need to think with Gerd about how to solve this), but in order to see first results, I changed the :message:`Found more than one account with IBAN xxx` error issued in :mod:`lino_cosi.lib.sepa.models` from an Exception to a simple logger warning. `Commit and push `_. I then had to reload their database from the nightly snapshot because :attr:`Account.partner ` is now nullable, i.e. the database structure has changed. With plain Django (1.7 or later) you would run migrations to do this. But with Lino it is easier to restore a dump which must of course have been generated before (see :ref:`lino.datamig`). I then understood a bug in the database structure: the `bank_account` field of a `sepa.Movement` must *not* be a pointer to `sepa.Account`. We do not want an Account object for all possible accounts in the world but only for those whose partner is known to us. I changed the name of that field from `bank_account` to `remote_account`. I added a field `remote_bic` (which can be blank) and have it be imported in :meth:`import_file `. Next two commits and pushes in :ref:`cosi` (`2 `__ and `3 `__) are for this. Second restore of their database from last snapshot. Each restore takes --admittedly-- about 10 minutes. This is certainly much more time than a regular database migration with Django would need. But for my customers (until now) it is no problem to have their server down during 10 minutes and to do such works only between 6pm and 8am. The advantage of my system (of reloading a snapshot instead of Django's migrations) is to be more flexible and more intuitive. Especially in situations like this one where I do a series of several quick changes in database structure. Imagine for example that I would discover now (during the second restore) that I have some stupid bug in the database structure which makes the resulting data unusable. With Django migrations such a bug would cause quite some work because I would need to manually edit the migrations. I have no experience with Django migrations, but until now I am satisfied with my system and don't feel a need to start using them. We will think about this more in detail when :ticket:`38` is finished and all my customers have upgraded... Yet another commit and push because I had need seen that the `remote_bank_bic` field of a :class:`BankTransaction ` defaults to `False` if the field is empty. Et voilà, finally I can invite Gerd to have a look at the imported data! It is a historic event for Lino because this is the first user-visible change which was mostly done by somebody else than me. #584 (Statistiques pour le Fonds Social Européen) ================================================= After feedback from Mathieu and Aurélie for :ticket:`584`, I wrote a first specification: :ref:`welfare.specs.esf` When to check clearings ======================= I continued on :ticket:`554`. The last session (:doc:`1014`) revealed the problem that Lino automatically runs :meth:`check_clearings ` for each document to be registered. While this is useful in daily work, it caused a serious bottleneck when importing 25000 vouchers. That's why I added a new option :attr:`auto_check_clearings ` per Journal whose default value is `True`, but :mod:`lino_xl.lib.tim2lino` sets it to `False`. TODO: add an action per partner which manually runs `check_clearings`.