Opened 3 years ago

Closed 3 years ago

#18368 closed New feature (wontfix) should be able to set attributes on created model instances

Reported by: geoffhing@… Owned by: nobody
Component: GIS Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


As far as I can tell, LayerMapping only allows populating a spatial model's attributes from the vector file. I recently had a use case where I needed to set other attributes of the model instances based on information not in the vector file.

I propose allowing an additional argument to that is a dictionary of initial field values that will be passed to the constructor of the spatial model.

That is, changing the method signature to be:

    def save(self, verbose=False, fid_range=False, step=False,
             progress=False, silent=False, stream=sys.stdout, strict=False,

and then inside save() around line 523, updating the keyword arguments passed to the model constructor:

                    # Add additional keyword arguments
                    if model_kwargs:

Change History (4)

comment:1 Changed 3 years ago by claudep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

I'm not thrilled by this proposed addition. I don't see anything here that cannot be done either by field default values on the model or by updating the created objects in a second pass.

comment:2 Changed 3 years ago by geoffhing@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

@claudep, I just want to make sure you're clear on the use case that made me request this. I'm bulk loading geometries using LayerMapping from a management command (code at The reason I needed to be able to pass additional model attributes to was to set a ForeignKey field to a model representing levels of a geographic hierarchy. In my use case, this field can be null, so that can't be used to identify the newly-created values. Also, geometries may be loaded at different times and for different levels of the geo hierarchy, so a default value for that field doesn't make sense.

Also, maybe I'm missing something, but I couldn't seem to find a way to retrieve the model instances created by Certainly, I could add a field to the model to indicate whether or not the model instances had been post-processed in a second pass, but preferred not to add fields to the model just to accommodate the occasional data load.

comment:3 follow-up: Changed 3 years ago by claudep

And what about post_save signal?

comment:4 in reply to: ↑ 3 Changed 3 years ago by geoffhing@…

  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to claudep:

And what about post_save signal?

You're absolutely right that signals are the way to go in this case. However, I think it would have to be the pre_save signal in my case. Thanks for the helpful observation.

Note: See TracTickets for help on using tickets.
Back to Top