Information Systems:Python development notes - early stages

From uniWIKI
Jump to navigation Jump to search

uniPHARM is no longer using open-source on IBM i. InfoNext has been migrated to uwdoss (Linux).

Notes

Random notes while learning to develop using Python on IBM i. A list of A-ha! moments.

  • Do not remove elements from a list while iterating over it.
  • For safety sake, do not run a database migration on an existing database that isn't managed by the ORM. Data will be deleted. Tables and columns can be restored by undoing the migration, but the data within is forever lost.
  • Related to the previous point, use a dedicated user to connect to the database, in programs and programming utilities (database managers). Do not connect to the database as yourself, your user profile has too much power.
  • If you don't commit your transactions (Connection.commit()), your SQL writes won't be written, no matter how many times you execute them.
  • When using ibm_db_dbi, execute 'SET SCHEMA' as if it were query statement (because it is) to effectively "change the library list".
  • When accessing Windows shares via QNTC (e.g. os module in Python), each level in the folder path cannot exceed 10 characters. Or was it 12-14?
  • When using ibm_db_dbi, connecting without parameters (ibm_db_dbi.connect()) will connect to the local instance of Db2.
  • IBM i authorities are not additive. Do not expect Linux- or Windows-like behavior.

Mini projects

So far I have experimented with many little things involving Python on IBM i, but most of the work is grouped into the following git code repositories:

  • inx - This is supposed to a mock Infonet built on Flask (which is like Django, but more barebones). Most of the work done so far has been in the alt_db branch that uses an external MySQL database (instead of Db2) and Python on an x86 VPS. This was to avoid 'playing' too much on the production system.
  • infonext - This came before inx, and was supposed to be a mock Infonet but in Django, before problems with the Django db adapter (ibm_db_django) on the i presented too many barriers. Switched to Flask so I could continue to learn while waiting on help from Krengeltech.
  • uwd_utils - Batch utilities in Python (e.g. Purolator invoice download). Some of this is actually used in production. Since these are non-interactive programs (no front-end thus no Django required), they were much easier to put to good use.
  • playground - Pure Python testing, nothing functional.