cxrodgers / mousecolony Goto Github PK
View Code? Open in Web Editor NEWDjango project for record-keeping for a mouse colony
Django project for record-keeping for a mouse colony
This is useful for keeping track of which mice are being used as breeders, and can be used to compute when a mouse should be retired from this role. We've decided to make this a Boolean rather than Breeder XOR behavior XOR whatever because a mouse can be both a breeder and serve in other capacities.
First Defunct, then Proprietor, then Name in reverse order.
Doesn't show up in the Mouse object view
When a breeding cage contains a male and female mouse (not including pups), there should be at least one Litter object. The date_mated should be the date that the mice were put in the cage.
This view should include every cage, which should in turn have some field or method (like infos) that displays all mice, their ages and genotypes, and any tasks to perform on that cage (this can be a custom method that traverses Task).
Right now 3004M and 3004F are appearing at the end, instead of between 3003 and 3005. May need to use lexsorting?
Given the new nomenclature that means every BreedingCage can have no more than one litter, does it make sense to make this a one-to-one relationship?
https://docs.djangoproject.com/en/1.9/topics/db/examples/one_to_one/
Will this break anything?
It seems more likely that we'll want to use names as a snapshot of all mice currently occupying a cage, rather than a record of all mice that were ever in a cage.
Drew needs to be able to print out the census view and it should be usable. This may work already if we simply fit to page. Another alternative would be to create a text-based "view".
Should 404 pages be shown (whether gunicorn is running or not)? What about other error pages?
Sometime we know a mouse was sacked but we don't know when. Can we add a dummy value to the drop-down list to represent this case? Alternative would be to reintroduce the Sacked boolean value.
There may be situations where toe-clipping has been put off until after P21. In this case, Litter.needs will currently display that the litter needs to be toe-clipped, but not that it needs to be weaned. This could lead to the user not realizing that the pups need to be weaned. Therefore, Litter.needs should somehow display that a litter needs be weaned on P21 even if it hasn't been toe-clipped yet.
Instead of manually specifying these fields, they should be calculated and reported by a class method that traverses to "litter" and "breeding_cage" to identify this info. But we also need a way to manually specify it for mice that have been grandfathered into the system, or were bought from Jackson, or for any other reason that that info might not be available.
For instance after they've been eaten or we conclude they are never coming
Some Tasks might reference a specific Mouse, others might refer to a Cage. Not really sure how we're planning on using Tasks.
I've been naming my litters DK.target_genotype.number, which often results in litter names longer than 20 characters.
It's sort of unclear why there is a "Needs" and a "needs" showing up on the Litter page. Also, why does it just say "parent" for "needs" when there is no info? Finally, need a way to disable the automatic generation of "needs" for old litters for which we don't know the dates of weaning, etc, but still want to have them in the database.
There are two main places where we'll see the mouse inline: 1) when we're adding mice to a litter in the litter admin, and 2) when we're looking at the occupants of a cage.
For case 1), we don't need the DOB in the mouse inline because they all have the same DOB as the litter. In case 2), the age of the mice is given in mouse info. So we probably don't need DOB in the mouse inline.
Useful to know when to give up on a breeding pair
There may be cases where an individual mouse has a user that is distinct from the proprietor of the cage.
It's not obvious how to do this as need_date is a custom method, not a database field.
One workaround would be to create an actual database field for need_date, then have that field updated as part of LitterAdmin's save_model method that gets called every time someone hits the "save" or "save and continue editing" button.
There may be some other ways using querysets that allow us to sort non-database field custom methods though.
Here's what I did
Using supervisord
Mouse currently has dob (a regular Django DateField) and auto_dob (a custom method that returns the dob of the parent litter if one exists).
For the most part, we will know when a mouse was born by looking at when its litter of origin was born. This is what auto_dob is for. For some cases, however, we may not have the litter information, and we may want to manually specify the birth date of a particular mouse. For these cases, we've retained dob, which is a regular Django DateField that can be manually edited in the change page for an individual mouse.
The issue now is that all mice have the manual dob field - including the ones for whom we have an auto_dob from the litter. For those mice that do have an auto_dob, the attributes dob and auto_dob should match; otherwise, one can imagine a situation where a mouse is given an auto_dob, but then when a user navigates to that mouse's individual change page, the manual dob field is confusingly blank.
We can accomplish this by overriding Mouse's save() method so that when a user is adding mice from the litter admin and presses the save button, Mouse's save() method checks if the mouse has a litter, and if so, sets the mouse's dob DateField to the litter's dob (this is the same approach used in issue #13 to automatically set a litter's proprietor to the proprietor of the breeding cage it came from).
Once the breeders are gone, no reason to keep labeling the pups as such. In general we want to highlight the mice that are breeding, not the mice that are pups.
Because these attributes define breedingcage, they should be required.
Something that checks for excessive access attempts or python errors and emails us about it
Can we have a brief paragraph of documentation / instructions on the top of each admin page explaining what the user can do on that page
Replace DOB column with age of litter.
Need a step-by-step checklist for importing people's data from various Excel sheets or whatever into the database
Right now it's "weaned" and "checked", but not the others, for some reason. If they are all editable it takes up too much screen space.
It should say something more relevant than "Django administration"
Although note that it's still necessary to know what the highest numbered cage is, even if it belongs to a different user.
"Notes" should be rightmost
"Cage" should default to currently viewing breeding cage
Unnecessary to display the litter number in the census view because it is always the same as the cage number
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.