summaryrefslogtreecommitdiff
path: root/docs/howto/custom-model-fields.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/howto/custom-model-fields.txt')
-rw-r--r--docs/howto/custom-model-fields.txt10
1 files changed, 10 insertions, 0 deletions
diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt
index daaede8e15..fcbda032b7 100644
--- a/docs/howto/custom-model-fields.txt
+++ b/docs/howto/custom-model-fields.txt
@@ -482,6 +482,16 @@ For example::
return ''.join([''.join(l) for l in (value.north,
value.east, value.south, value.west)])
+.. warning::
+
+ If your custom field uses the ``CHAR``, ``VARCHAR`` or ``TEXT``
+ types for MySQL, you must make sure that :meth:`.get_prep_value`
+ always returns a string type. MySQL performs flexible and unexpected
+ matching when a query is performed on these types and the provided
+ value is an integer, which can cause queries to include unexpected
+ objects in their results. This problem cannot occur if you always
+ return a string type from :meth:`.get_prep_value`.
+
Converting query values to database values
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~