<p>Troggle is built on top of the django framework. In 2019 we had let ourselves get rather behind in keeping up to date with the current django version and this held us back from upgrading the operating system - which we needed to do. Troggle uses several community-contributed django plugins and each of these had their own version dependencies. We also got caught up with out of date and deprecated python language features.
<p>A ridiculous amount of work was required to get to a situation where troggle was running on relatively recent and nearly security-in-date versions of python, django, plugins and linux by Summer 2020. We don't want that to happen again.
<li>There are many 'magic' function calls autogenerated. So when we create a <var>'Cave'</var> class (subclass of Django <var>Model</var>), with an instance <var>'caveenetrance'</var> we automagically define functions such as:
note that the suffix on a name '<var>'_set</var> actually denotes a function call to the database on an object of class "CaveAndEntrance". Don't let this upset you. (The underline character and lower-casing denotes a dereferencing operation in Django queries.)
<li>You will get very familiar with the <ahref="https://docs.djangoproject.com/en/3.2/">online documentation</a>. be sure to be looking that the flavour for the right release of Django (indicated on the bottom-right of the screen: the link here goes to v3.2). You can read it in Polish, Indonesian, Brazilian-Portuguese or whatever if you prefer.
<li>Django has a good process for migrating both the python code and the SQL database to later versions of Django via <ahref="https://docs.djangoproject.com/en/dev/topics/migrations/">'migrations'</a>. Note that even though Expo imports all the data from files and its database is ephemeral (but it is intensely used for cross-referencing), the database schema still needs to be migrated.
<li>Django has a mature and reliable release programme: <ahref="https://docs.djangoproject.com/en/dev/releases/">docs.djangoproject.com<wbr>/en/<wbr>dev/<wbr>releases/</a>
<li>Django pre-announces which features will be deprecated: <ahref="https://docs.djangoproject.com/en/dev/internals/deprecation/">docs.djangoproject.com<wbr>/en/<wbr>dev/<wbr>internals/<wbr>deprecation/</a>
<p>This may seem overly pedantic and heavyweight, but this is exactly what we need when we are supporting software over decades. When we use software in troggle which is not so well organised, we really feel the pain.
<p>We do not just use our own code and django. We also use django plugins (known as "apps") too. These can do such things as image re-sizing, user authentication with captchas, PayPal processing or mailing list integration. Unfortunately django plugins are volunteer efforts and do not have the same defined update management process as django itself, so release schedules are rather random. They cause merry hell when upgrading troggle to use a new version of django.
<li>SQL database: <ahref="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries (sqlite, MySQL, MariaDB, postgres all work). This is where the multi-user synchronisation happens too.
<li>request/response (<ahref="https://docs.djangoproject.com/en/dev/ref/request-response/">http GET/POST</a>) including <ahref="https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests">access control</a> and <ahref="https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/">security middleware</a>. We could never keep up with web security if we didn't use a well-supported system for this.
<li><ahref="https://docs.djangoproject.com/en/dev/topics/http/urls/">URL mapping/dispatch</a> which matches a requested URL with a chunk of python code, and vice versa (declarative and bidrectional). "Cool URIs don't change."
<li><ahref="https://docs.djangoproject.com/en/dev/topics/templates/">templates</a> which format the results of data queries into HTML pages or JSON data exports
<p>See the <ahref="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a> on 'loose coupling and tight cohesion'. Note that having a URL dispatcher that supports
<p>[This section, and the <ahref="#3sent">3-sentence intro</a>, to go to another page ?]
<p>Much of our coding is still stuck in the early Django v1 era, before 2011. So many idioms in the code are not the best way of doing things these days. In particular there are powerful query optimisations now available that none of our code uses (yet):
<ul>
<li><ahref="https://ctrlzblog.com/django-queryset-filter-15-examples/">.distinct()</a> - returns a list with no duplicated items, and many other clever filters
<li><ahref="https://zerotobyte.com/how-to-use-django-select-related-and-prefetch-related/">select_related()</a>– creates INNER JOIN between tables
<li><ahref="https://hakibenita.com/all-you-need-to-know-about-prefetching-in-django">prefetch_related()</a>– connects tables using Python (but queries both tables)
</ul>
and also much more about the manipulation of QuerySets:
<ul>
<li><ahref="https://docs.djangoproject.com/en/dev/ref/models/querysets/#bulk-create">bulk_create()</a> - just started using it in data imports in 2023.
</ul>
<h4>More refactoring still to do</h4>
<p>Some of the more bizarre data model structures are probably fossils from Django v0.6, e.g. the separate classes that join Entrances to Caves. We haven't got to the bottom of all these yet.
<p>Just don't. Django has several generations of quite different clever mechanisms to make creating HTML forms "easier". Yes, making them might be easier, but maintaining this opinionated stuff is a nightmare. Really don't.
