object database weebling

This commit is contained in:
Philip Sargent 2021-03-21 23:25:03 +00:00
parent d0a41d386c
commit 24f31f32e9
2 changed files with 6 additions and 4 deletions

View File

@ -12,7 +12,7 @@
<h2>5-Year Plan</h2>
<p>[Philip Sargent, 1 June 2020]
<ul>
<li>I reckon django has at least another 4-5 years left as a very active project (~2025).
<li>I reckon django has at least another 4-5 years left as a very active project (~2025) and at least a decade or so as a well-maintained project.
<li>I reckon python has another 10-20 years at least.
<li>I reckon SQL databases have another 30 years at least.
</ul>
@ -41,7 +41,9 @@ https://martinfowler.com/bliki/BranchByAbstraction.html">
<h3>Option 2A</h2>
<p>
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
<a href="https://www.mongodb.com/">MongoDb</a> or the
<a href="https://en.wikipedia.org/wiki/Zope_Object_Database">Zope Object Database</a> (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: <a href="https://daniel.feldroy.com/when-to-use-mongodb-with-django.html">Short answer is you don't use MongoDB with Django</a> 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.]
<h3>Option Zero</h2>
@ -60,7 +62,7 @@ A GIS db could make a lot of sense. Not in scope for this discussion.
<p>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.
<h3>API</h3>
<p>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.
<p>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 <a href="">what CUYC do</a>
<h3>Postscript</h3>
<p>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:

View File

@ -47,7 +47,7 @@ Troggle is written in Python (about 6,400 lines excluding comments) and is built
<p>
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 <a href="https://docs.djangoproject.com/en/3.0/misc/design-philosophies/">django design philosophy</a> 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 <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a> 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.
<p>We have to keep up to date with new rleases of django, see <a href="trogdjango.html">Upgrading Django for Troggle</a>.