MGR CMS: a simple Django-based content management system for genomic data

MGR-CMS (Mint Genomics Resource) is a content management system for genomic and transcriptomic data. The code for MGR-CMS can be found Here. As implied by the name, it was originally built to house data for mint plants, but it can be easily adapted for data from other organisms. I made MGR because I couldn't figure out how to get Tripal to behave how I wanted it to. I later found out that was my fault, not Tripal's fault, so if you want a more or less feature complete genomics content management system, look there. If you want a simple system written in Python (Django), or you have the misfortune of having a Windows server (as I do), then MGR might be just the thing for you (but it still might be worth your while to shoot the Tripal people an e-mail, just to make sure it really can't handle your situation).

building a django app that uses ZeroMQ: an annotated webliography

Introduction:
I wanted to build a website that allows people to search their data against a database (in the not too distant future, when the website is live I'll link it and the source code and give more of an explanation. Edit: and here it is, the code, the ZeroMQ stuff is mostly at "/nmr/management/commands", and the website ). Each search takes a few seconds, so in order to be able to serve multiple clients at a time, and allow scaling, I wanted to build a system where the main wsgi process does not block, but passes the search request off to another process that puts it in a queue and executes requests in the queue one by one. I ended up following a simple approach using ZeroMQ. There is a scheduler that runs as a thread in the main wsgi process. When the search input view receives a search request, it writes the search parameters into the database and opens a connection to the scheduler thread and passes it the unique ID of the database record storing the search parameters. There are one or more worker processes each running as a subprocess. The workers are permanently attached via a socket to the scheduler. When a worker completes a job, the scheduler sends it the ID of the next job in the queue, the worker executes the job, writes the results in a database table, and tells the scheduler it is ready for another job. There can be many workers attached to the scheduler, so that multiple searches can be run concurrently.

Here then is a list of (some of) the websites I used for reference while writing this program.