Hi, I’ve been asked by Mariusz to take the discussion of ticket #34915 here. My suggestion was to:
If a model has the Meta option
order_with_respect_to, new instances of the model have the_orderfield autopopulated, no matter if it is already set or not. I propose to only set the field if it has not previously been set already, allowing a custom order to be set before saving new objects, and saving a query to the database in this case.This will not affect existing code that does not explicitly set the _order field before saving the object.
Mariusz reply (wontfix) was:
Thanks for this ticket, however, I don’t understand why you want to set ordering with respect to the given field and in the same time set it manually. It seems that you should use your own custom logic for ordering and disable
order_with_respect_to. The proposed behavior would be confusing and counterintuitive.
I’d like to have the cake and eat it, too, because I like the interface of order_with_respect_to as well as the automatic addition of the _order field - less boilerplate in my code. But I’d like to be able to set the order already on newly created objects, and not only on existing ones. The interface already includes .set_RELATED_order(), so setting the order manually is not going against the spirit of order_with_respect_to.
The suggested change is minimally intrusive, and doesn’t change the behavior for code that doesn’t touch the _order field explicitly. At least one developer found the current behavior confusing, namely that an already populated field gets autopopulated regardless, overwriting my explicit setting. With the current implementation, I have to make sure that the objects are created in the desired order - I would find it more intuitive if setting _order gets honored, and only falling back to autopopulation if not populated already.
What does the wider community thinks about the proposed change?
Cheers, Til