From 24f31f32e9550818edc5f1a9c5828dc6aceff5bc Mon Sep 17 00:00:00 2001 From: Philip Sargent Date: Sun, 21 Mar 2021 23:25:03 +0000 Subject: [PATCH] object database weebling --- handbook/troggle/trog2030.html | 8 +++++--- handbook/troggle/trogarch.html | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/handbook/troggle/trog2030.html b/handbook/troggle/trog2030.html index 362083689..d323d2b89 100644 --- a/handbook/troggle/trog2030.html +++ b/handbook/troggle/trog2030.html @@ -12,7 +12,7 @@

5-Year Plan

[Philip Sargent, 1 June 2020]

@@ -41,7 +41,9 @@ https://martinfowler.com/bliki/BranchByAbstraction.html">

Option 2A

-We also use a noSQL db with a direct and easy mapping to python collections. +We also use a noSQL db with a direct and easy mapping to python collections. The obvious candidates are +MongoDb or the +Zope Object Database (ZODB). MongoDb is famous and programmers may want to work on it to get the experience, but ZODB is much closer to python. But ZODB is now rather old, and the Django package django-zodb has not been updated for 10 years. And MongoDb has a bad impedence mismatch: Short answer is you don't use MongoDB with Django which creates a lot of extra pointless work. If we ever need atomic transactions we should use a database and not try to fudge things ourselves, but not either of those. [This needs to be explored, but I suspect we don't gain much compared with the effort of forcing maintainers to learn a new query language. Shelve() is already adequate.]

Option Zero

@@ -60,7 +62,7 @@ A GIS db could make a lot of sense. Not in scope for this discussion.

There is not yet a front-end (javascript) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit effort to. Bits of troggle use very old jQuery ("edit this page", and the svx file editor) , and Flask looks interesting, but maybe in 2025 we could see a good way to move all the user interface to the client and just have an API on the server.

API

-

We will also need an API now-ish, whatever we do, so that keen kids can write their own special-purpose front-ends using new cool toys. Which will keep them out of our hair. +

We will also need an API now-ish, whatever we do, so that keen kids can write their own special-purpose front-ends using new cool toys. Which will keep them out of our hair. We can do this easily with Django templates that generate JSON, which is what CUYC do

Postscript

Andy Waddington, who wrote the first expo website in 1996, mentioned that he could never get the hang of Django at all, and working with SQL databases would require some serious book-revision: diff --git a/handbook/troggle/trogarch.html b/handbook/troggle/trogarch.html index 954951ee6..4203bf61c 100644 --- a/handbook/troggle/trogarch.html +++ b/handbook/troggle/trogarch.html @@ -47,7 +47,7 @@ Troggle is written in Python (about 6,400 lines excluding comments) and is built

Django is the thing that puts the survey data in a database in a way that helps us write far less code to get it in and out again, and provides templates which make it quicker to maintain all the webpages. -See the django design philosophy for why we chose it: while django comes with a full stack (db, request/response, URL mapping, HTML templates) the layers of the stack are independent and individually replaceable. +See the django design philosophy for why we chose it: while django comes with a full stack (db, request/response, URL mapping, HTML templates) the layers of the stack are independent and individually replaceable.

We have to keep up to date with new rleases of django, see Upgrading Django for Troggle.