When creating a CharField, the max_length appears to apply to the decrypted value, not the encrypted value, which is much longer. This can result in database errors as the ORM tries to insert a large encrypted value into a column that expects much smaller data. This isn't a problem in SQLite, which doesn't strictly enforce these things at the database level, but other backends can have issues.
By having this example:
name = models.CharField(max_length=50)
sensitive_data = encrypt(models.CharField(max_length=50))
It implies that simply wrapping a field in encrypt "just works", but in our experience we also need to consider the size of the encrypted value and adjust the max_length accordingly. I think at the very least the example should point out that you may need to adjust the max_length to accommodate the encrypted value's size.
You might want to take a look at django-encrypted-model-fields, which claims to automatically increase the max_length for the encrypted value. For example max_length=3 will result in a 100-character size in the database.
When creating a
CharField, themax_lengthappears to apply to the decrypted value, not the encrypted value, which is much longer. This can result in database errors as the ORM tries to insert a large encrypted value into a column that expects much smaller data. This isn't a problem in SQLite, which doesn't strictly enforce these things at the database level, but other backends can have issues.By having this example:
It implies that simply wrapping a field in
encrypt"just works", but in our experience we also need to consider the size of the encrypted value and adjust themax_lengthaccordingly. I think at the very least the example should point out that you may need to adjust themax_lengthto accommodate the encrypted value's size.You might want to take a look at
django-encrypted-model-fields, which claims to automatically increase themax_lengthfor the encrypted value. For examplemax_length=3will result in a 100-character size in the database.cc @alex-ccsd