Should the General hierarchies be hard-coded?

[bhaugen]

Looks like they pretty much are now. See https://github.com/FreedomCoop/valuenetwork/blob/exchanges/general/models.py

I can see some tradeoffs here.

Facets and FacetValues in OCP are not hard-coded. They can be redefined for every installation, and for every project. The problem is that then they need to be configured, and configuring them seems to be difficult for many (if not most) people. And you can create configuration bugs. It's not as bad as needing to make program changes, and changes do not need programmers or redeployment of the software, but it's almost as bad as programming.

Because the General app categories and hierarchies are hard-coded, that means nobody needs to do much configuration. The configuration has mostly been done. On the other hand, changes to the categories and hierarchies will require reprogramming.

Another tradeoff here is that if we can get general consensus on a hierarchical classification, and they are built-into the software and everybody uses them, then it might help with interoperability. On the other hand, it prevents different projects and communities from creating their own different classifications, unless they fork and change the software.

I suspect this will become an issue in the django-rea refactoring project...

Note: this is a different issue than the advantages and disadvantages of hierarchical vs faceted categories. Facets are more flexible, but seem to be more difficult for people to understand, than hierarchies, possibly because of cultural training. But that's another case of tradeoffs, and it's probably good that we can get some experience in OCP to see how some of those tradeoffs work in practice.

[bum2]

I don't think the trees are hardcoded, they just try to be common (at least a starting set). There are only some hardcoded identifiers in the code to easily get some special types used in the app, via the 'clas' field (in every GA type, useful for this kind of 'fast get' or to specify a custom model class name). These are the ones that need a fixture to pre-set them on installation time. Are only a few to easily find eg. a 'currency' parent type, or things like that, but all the other items in the trees can be organised at will...

Many of the hardcoded strings in valueaccounting like field options, relations and so, can be placed as real db records and get them with an identifier on their grouping parent type... one day we can play with that... The GA goal is to have all possible data in the db instead of the code, so it can be configured for every need. Is much more 'less hardcoded' than valueaccounting imho.

The facets and facetvalues are running behind the aparent trees: the root types branches are normally related facets and the main branches inside are related facetvalues... still is not automated the creation of new facetvalues when a resource type becames a parent of some childs, but now shows the option for admins when that happens (to autocreate the facetvalue when saving, but still not happens).

The resource type trees are using only a part of the facet-value system (3 facets: Material, Non-material and Skills), and now another facet is being used for separating the currency types, not related the resource types. So the power of FV is used and it will be used much more when the needs arise. The trees just gives a easier interface to organisation of facets, facetvalues and types, and brings a new dimension to them. They can be used also like tags, but that will be for another release...

[bhaugen]

Hard-coded in https://github.com/FreedomCoop/valuenetwork/blob/exchanges/general/models.py : (these are just excerpts, there's a lot lot more)

class Being(models.Model):
class Human(Being):
class Person(Human):
class Project(MPTTModel, Human):
class Company(Human):
class rel_Human_Jobs(models.Model):
class rel_Human_Addresses(models.Model):
class rel_Human_Regions(models.Model):
class rel_Human_Records(models.Model):
class rel_Human_Materials(models.Model):
class rel_Human_Nonmaterials(models.Model):
class rel_Human_Persons(models.Model):
class rel_Human_Projects(models.Model):
class rel_Human_Companies(models.Model):
class Art(MPTTModel):
class Job(Art):
class Space(models.Model):
class Artwork(models.Model):
class rel_Nonmaterial_Records(models.Model):
class rel_Nonmaterial_Addresses(models.Model):
class rel_Nonmaterial_Jobs(models.Model):
class rel_Nonmaterial_Nonmaterials(models.Model):

I'm not saying this is a bad thing. As I wrote above, there's tradeoffs here. If rough consensus is achieved on a set of hierarchical classifications, and they are hard-coded, then nobody needs to configure them. The disadvantage is that different groups can't have different sets without forking and reprogramming.

It's also possible that hard-coding is a good starting point, and then the trees can be made more configurable later when they need to be.

[bhaugen]

@bum2

Many of the hardcoded strings in valueaccounting like field options, relations and so, can be placed as real db records and get them with an identifier on their grouping parent type... one day we can play with that... The GA goal is to have all possible data in the db instead of the code, so it can be configured for every need. Is much more 'less hardcoded' than valueaccounting imho.

I don't want to compete about who's got the most hard-codings. I certainly did more than my share. But I wanted to ask about your comment because it might explain more about where you are going with your General app. Some of your basic goals that might not be apparent to me (or not yet, anyway).

Is your goal to have the fields and relationships be defined in the DB? That's interesting, and I'd be interested in some examples of how you are using that technique.

How about the methods?

There is a set of concepts and relationships in valueaccounting that comes from REA that are minimal necessities for an economic network. Sooner or later, each of them will be needed. They have been reviewed and discussed around the world for 30+ years and are an ISO standard. All of that stuff has logic attached, and some of it is necessary.

Then there's a lot of stuff that we added. Some pretty hacky, mostly done by me. I am often a get-it-done programmer. One of my coding mentors was Kent Beck, whose motto was "make it work, make it right, then make it fast". So my first goal is to make it work. Lynn is a lot less hacky.

People (including some of our REA friends) have done al the REA stuff so it's all defined in a DB, but those were code-generation environments, the DB definitions were not consulted at runtime.