Changeset 8215 for django/branches/gis/docs/custom_model_fields.txt
- Timestamp:
- 08/05/08 12:15:33 (5 months ago)
- Files:
-
- django/branches/gis (modified) (1 prop)
- django/branches/gis/docs/custom_model_fields.txt (modified) (8 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/branches/gis
- Property svnmerge-integrated changed from /django/trunk:1-7978 to /django/trunk:1-8214
django/branches/gis/docs/custom_model_fields.txt
r7979 r8215 112 112 of the class behavior. 113 113 114 .. _form fields: ../ newforms/#fields114 .. _form fields: ../forms/#fields 115 115 116 116 It's important to realize that a Django field class is not what is stored in … … 386 386 mentioned earlier. Otherwise ``to_python()`` won't be called automatically. 387 387 388 ``get_db_prep_ save(self, value)``389 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 388 ``get_db_prep_value(self, value)`` 389 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 390 390 391 391 This is the reverse of ``to_python()`` when working with the database backends … … 400 400 # ... 401 401 402 def get_db_prep_ save(self, value):402 def get_db_prep_value(self, value): 403 403 return ''.join([''.join(l) for l in (value.north, 404 404 value.east, value.south, value.west)]) 405 406 ``get_db_prep_save(self, value)`` 407 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 408 409 Same as the above, but called when the Field value must be *saved* to the 410 database. As the default implementation just calls ``get_db_prep_value``, you 411 shouldn't need to implement this method unless your custom field need a special 412 conversion when being saved that is not the same as the used for normal query 413 parameters (which is implemented by ``get_db_prep_value``). 414 405 415 406 416 ``pre_save(self, model_instance, add)`` … … 441 451 442 452 If you needed to implement ``get_db_prep_save()``, you will usually need to 443 implement ``get_db_prep_lookup()``. The usual reason is because of the 444 ``range`` and ``in`` lookups. In these case, you will passed a list of 445 objects (presumably of the right type) and will need to convert them to a list 446 of things of the right type for passing to the database. Sometimes you can 447 reuse ``get_db_prep_save()``, or at least factor out some common pieces from 448 both methods into a help function. 449 450 For example:: 453 implement ``get_db_prep_lookup()``. If you don't, ``get_db_prep_value`` will be 454 called by the default implementation, to manage ``exact``, ``gt``, ``gte``, 455 ``lt``, ``lte``, ``in`` and ``range`` lookups. 456 457 You may also want to implement this method to limit the lookup types that could 458 be used with your custom field type. 459 460 Note that, for ``range`` and ``in`` lookups, ``get_db_prep_lookup`` will receive 461 a list of objects (presumably of the right type) and will need to convert them 462 to a list of things of the right type for passing to the database. Most of the 463 time, you can reuse ``get_db_prep_value()``, or at least factor out some common 464 pieces. 465 466 For example, the following code implements ``get_db_prep_lookup`` to limit the 467 accepted lookup types to ``exact`` and ``in``:: 451 468 452 469 class HandField(models.Field): … … 456 473 # We only handle 'exact' and 'in'. All others are errors. 457 474 if lookup_type == 'exact': 458 return self.get_db_prep_ save(value)475 return self.get_db_prep_value(value) 459 476 elif lookup_type == 'in': 460 return [self.get_db_prep_ save(v) for v in value]477 return [self.get_db_prep_value(v) for v in value] 461 478 else: 462 479 raise TypeError('Lookup type %r not supported.' % lookup_type) … … 494 511 fields. 495 512 496 .. _helper functions: ../ newforms/#generating-forms-for-models497 .. _forms documentation: ../ newforms/513 .. _helper functions: ../forms/#generating-forms-for-models 514 .. _forms documentation: ../forms/ 498 515 499 516 ``get_internal_type(self)`` … … 539 556 serialization, the API might change in the future. 540 557 541 Returns a dictionary, mapping the field's attribute name to a flattened string542 version of the data. This method has some internal uses that aren't of 543 interest to use here (mostly having to do with manipulators). For our 544 purposes, it's sufficient to return a one item dictionary that maps the 545 attribute name to a string.558 Returns a dictionary, mapping the field's attribute name to a 559 flattened string version of the data. This method has some internal 560 uses that aren't of interest to use here (mostly having to do with 561 forms). For our purposes, it's sufficient to return a one item 562 dictionary that maps the attribute name to a string. 546 563 547 564 This method is used by the serializers to convert the field into a string for … … 558 575 def flatten_data(self, follow, obj=None): 559 576 value = self._get_val_from_obj(obj) 560 return {self.attname: self.get_db_prep_ save(value)}577 return {self.attname: self.get_db_prep_value(value)} 561 578 562 579 Some general advice
