Refactor klp/models.py

[batpad]

So, we seem to have a complete set of models generated from the current db, including the view tables, and testing querying through the ORM in the shell seems to work quite okay.

Now, do we want to refactor a bit, and how?

• Do we split up the models into separate apps?
• Inheritance structure: can we think of creating some abstract base models to inherit from?
• Some idea of what kind of stuff we would want custom managers for? What conventions should we use for model method names, etc.?

Eg. Look at current "School" model in klp/models.py with some basic model methods.

[batpad]

So, we've decided to make separate files inside a models folder like maybe models/school.py , models/assessments.py or so, just to logically group the various models so it is not this one large file.

@meghaklp is it possible for you to go through the models file: https://github.com/klpdotorg/dubdubdub/blob/develop/apps/klp/models.py - there is one model defined for each table in the klpwww_ver4 db .. if you could logically group them into perhaps 3-5 different groups, in whatever way is convenient -- just creating a listing of groups with table names should be fine .. or just copy paste the various models there into separate files, then I can go ahead and integrate it in. Thanks!

[meghaklp]

https://docs.google.com/a/klp.org.in/document/d/10BO_nOt0-VvzbN0waFy0UCQDGgNQ7uZJGSw2YVL8DmI/edit?usp=sharing

[meghaklp]

I didn't know how to use this github reviewing thing, without referring to individual commits, so the google doc.

[meghaklp]

Also about the grouping -

Group 1: {Boundary, Boundary type, heirarchy Institution, Address and all the attributes like moi, mgmt Student, Child, Class, Teacher, Student-class association, Teacher to class association and their attributes like sex, mt }

can all be in one file, because they define whole Education system. If you want to split it further go ahead. But I believe there are linkages between some of these tables.

Group 2: {Partner, Programme, Assessment, Questions, StudentEval/Answer, Assessment Info/Agg}

can be in one file because they are an intervention on the above system, by a partner.

Group 3: {Library, DISE, APMDM, Sikshana (which is not there right now)}

Views of partner data that don't fit into over assessment model can be in one group. We maybe in future be able to merge this with the above group.

Group 4: {Coords}

Group 5 ? : {Elected Rep info, school elected rep linkages} We could consider merging this with Coord, if in future we are computing these linkages through reverse geo-coding only. I'm not sure where Elected Rep info should sit, maybe independently in the Partner data group... shrug

[batpad]

Ok.

So, I think the plan here would be to split up the models file into these 5 groups as identified by @meghaklp and put it in a models/ folder under the klp app, with an init.py that imports all of them - this would essentially just be for aesthetic grouping reasons, so we don't have one giant models file.

@vinayakh @iambibhas @geohacker , if the above sounds reasonable, I'll go ahead with it.

[geohacker]

Sounds good to me!

[batpad]

Also, will create a base.py in the models folder with a BaseModel and a BaseGeoModel to serve as general base classes for all models.

[batpad]

this refactor seems done - if there are other concerns with the models structure, lets open separate tickets, marking as closed.