Django

Code

Ticket #3982 (closed: fixed)

Opened 2 years ago

Last modified 1 year ago

Allow Field subclasses to coerce arbitrary Python types

Reported by: Marty Alchin <gulopine@gamemusic.org> Assigned to: nobody
Milestone: Component: Database layer (models, ORM)
Version: SVN Keywords: coerce coercion
Cc: jm.bugtracking@gmail.com, elsdoerfer@gmail.com Triage Stage: Unreviewed
Has patch: 1 Needs documentation: 1
Needs tests: 1 Patch needs improvement: 1

Description

In working with a recent DurationField patch (#2443), I noticed that Django seems to rely on the backend database driver to coerce data into native Python types. However, when adding new fields with non-standard mappings (such as FloatField for storage, but timedelta as a native type, as in DurationField), to_python needs to be called explicitly when populating an object from the database in order to be usable. This simple patch does just that, using to_python to coerce native Python types, after whatever coercion might be done by the database.

Attachments

to_python.diff (0.8 kB) - added by Marty Alchin <gulopine@gamemusic.org> on 04/09/07 22:07:06.
Path to force to_python data type coercion during data retrieval
coerce.diff (0.8 kB) - added by Marty Alchin <gulopine@gamemusic.org> on 05/15/07 18:36:08.
Adds support for a coerce Field method to handle coercion
lazy_attribute.diff (2.1 kB) - added by Marty Alchin <gulopine@gamemusic.org> on 05/27/07 22:51:05.
An attempt at generic lazily-instantiated attributes

Change History

04/09/07 22:07:06 changed by Marty Alchin <gulopine@gamemusic.org>

  • attachment to_python.diff added.

Path to force to_python data type coercion during data retrieval

05/15/07 18:36:08 changed by Marty Alchin <gulopine@gamemusic.org>

  • attachment coerce.diff added.

Adds support for a coerce Field method to handle coercion

05/15/07 18:45:37 changed by Marty Alchin <gulopine@gamemusic.org>

  • keywords changed from to_python to coerce coercion.
  • needs_better_patch changed.
  • summary changed from [patch] Use fields' to_python to coerce Python data types to Allow Field subclasses to coerce arbitrary Python types.
  • needs_tests changed.
  • needs_docs changed.

The attached patch allows Field subclasses to define a coerce method that takes a single value and returns any Python type, that will then be attached to the model instance as the appropriate attribute. This happens after retrieval from the database, manual instantiation of objects, and deserialization.

The one pitfall is that, due to the way bits of Django work, the value sent to coerce might be:

  • a string (if the model came from the DB)
  • a native Python type (if it came from a serializer, having already gone through to_python)
  • possibly some other situation I haven't run into yet

So the coerce method should take these different situations into account.

Here's an example, from DurationField, which will be added to #2443 soon. 

def coerce(self, value):
    return datetime.timedelta(seconds=float(value))

05/15/07 18:46:43 changed by Marty Alchin <gulopine@gamemusic.org>

  • needs_better_patch set to 1.
  • needs_tests set to 1.
  • needs_docs set to 1.

I forgot to add all the checkboxes, since there's much more needed to call this done.

05/17/07 20:02:52 changed by anonymous

  • cc set to jm.bugtracking@gmail.com.

05/27/07 22:51:05 changed by Marty Alchin <gulopine@gamemusic.org>

  • attachment lazy_attribute.diff added.

An attempt at generic lazily-instantiated attributes

05/27/07 22:53:56 changed by Marty Alchin <gulopine@gamemusic.org>

In speaking with Robert Coup and seeing his thoughts on #4322, I've come up with a way for Field subclasses to more easily implement lazy instantiation. I'll be demonstrating this method in #2443 as well as working with Robert on a new patch for #4322.

05/28/07 20:59:10 changed by mtredinnick

  • owner changed from adrian to mtredinnick.

There's some issue drift going on here. The last patch has close to nothing to do with the original ticket, which is essentially about helping create Field sub-classes. Lazy instantion is not a requirement there and is an orthogonal issue. Let's try to keep one issue per ticket, please.

I'm going to get around to tidying up the various Field sub-classing ticket this week and I'll close this when that happens. You should open another ticket for the lazy portion after that (probably best to wait until then so that you can write a patch against the code that exists in trunk).

05/28/07 21:32:41 changed by Marty Alchin <gulopine@gamemusic.org>

Yeah, I admit there is some drift here, but it's mainly because lazy instantiation seems to be a better approach to solve the original problem this ticket was opened for. I'll wait and see the results of your work this week, and if this one needs to just close as an invalid, I'm fine with that.

07/18/07 11:51:46 changed by miracle2k <elsdoerfer@gmail.com>

  • cc changed from jm.bugtracking@gmail.com to jm.bugtracking@gmail.com, elsdoerfer@gmail.com.

Would be nice if this could be fixd at some point. Field subclassing is severely limited currently.

12/01/07 11:15:34 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

Looks like this was fixed with the addition of SubFieldBase and the whole field subclassing stuff.

Add/Change #3982 (Allow Field subclasses to coerce arbitrary Python types)




Change Properties
Action