When you want to save integers to the db, you usually have the choice between 16-, 32- and 64-bit Integers (also 8- and 24-bit for MySQL). If that doesn't fit your needs and you want to use your db-memory more efficient, this field might be handy to you.
Imagine you have 3 numbers, but need only 10 bit to encode each (i.e. from 0 to 1000). Instead of creating 3 smallint-fields (48 bit), you can create one 'ByteSplitterField' which implements 3 'subfields' and automatically encodes them inside a 32 bit integer. You don't have to take care how each 10-bit chunk is encoded into the 32-bit integer, it's all handled by the field (see also field's description).
Additionally, the Field offers opportunity to use decimal_places for each of your subfields. These are 'binary decimal places', meaning the integer-content is automatically divided by 2, 4, 8, etc. when you fetch the value from the field.
You can also specify how values are rounded ('round' parameter) and what happens when you try to save a value out of range ('overflow' parameter)
Not implemented (maybe in the future if I should need it sometime):
* signed values. All values are positive right now!
* real (10-based) decimal places (actually you could probably directly use DecimalFields here)
* further space optimization, i.e. saving into CharField that's length can be chosen byte-wise
- model
- db
- database
- field
- custom
- custom-model-field
- IntegerField
- multibit-field
- model-field
This is a portion of my code for creating a hierarchical relation between assemblies, subparts, and parts and so forth (although really, everything is a Part)
The project being used is [django_dag](https://github.com/elpaso/django-dag)
For the sake of example, let's use this structure:
* Bike 1
* - Front Tire & Back Tire combo 000
* - - Front Tire 000
* - - Rear Tire 000
* - Frame 000
* - Gearset type 000
* - - Crank 000
* - - Rear Cassette 000
* .
* Bike 2
* - Front Tire & Back Tire combo 001
* - - Front Tire 001
* - - Rear Tire 000
* - Frame 001
* - Gearset type 000
* - - Crank 000
* - - Rear Cassette 000
Using the above example, I couldn't use a MPTT structure because Gearset 000 is used in 2 different parents (bike 1 and bike 2). So I had to use the DAG [(wiki)](http://en.wikipedia.org/wiki/Directed_acyclic_graph) structure which allows multiple parents.
The `Relationship` model holds the dag information, mainly a parent and child field. (Tire combo 001 is child of Bike2, front tire 001 is child of tire combo 001, etc)
After get the dag structure using the `ancestors_tree` method on a Part object, I search for the BillOfMaterial info for that whole tree.
In my case the Bill Of Material info is unique per assembly, so that's why there are seperate models.
It becomes a bit of a pain to have to save/delete both the relationship and BoM models at the same time, and to check if one exists to create the other etc. But I've made my first 'hack' through it to have a function project, and am ready to make some revisions now.
- models
- hierarchy
- dhango_dag
- django-dag