Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#17799 closed Bug (fixed)

Default parameters in syncdb.Command().Execute()

Reported by: kacah222@… Owned by: nobody
Component: Core (Management commands) Version: 1.4-beta-1
Severity: Normal Keywords: syncdb
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Trying to run syncdb.Command().Execute() command there is an error

TypeError: int() argument must be a string or a number, not 'NoneType'

Reason: no default values specified in syncdb.handle_noargs

Fix in attach.

Attachments (2)

syncdb.patch (818 bytes ) - added by kacah222@… 12 years ago.
17799-2.diff (1.2 KB ) - added by Claude Paroz 12 years ago.
Doc updated with note about execute

Download all attachments as: .zip

Change History (7)

by kacah222@…, 12 years ago

Attachment: syncdb.patch added

comment:2 by Ramiro Morales, 12 years ago

Triage Stage: AcceptedDesign decision needed

comment:3 by Claude Paroz, 12 years ago

I suddenly realized that call_command was working around this by picking defaults from klass.option_list.

    # Grab out a list of defaults from the options. optparse does this for us
    # when the script runs from the command line, but since call_command can
    # be called programatically, we need to simulate the loading and handling
    # of defaults (see #10080 for details).

Either we stick with the comment in call_command (and specifically add in the docs that execute should not be called directly):

This is the primary API you should use for calling specific commands.

Or we move the defaults value grabbing from call_command to execute (conditionally only when it is not run from command line).

This might be the real design decision to make.

by Claude Paroz, 12 years ago

Attachment: 17799-2.diff added

Doc updated with note about execute

comment:4 by Carl Meyer, 12 years ago

Resolution: fixed
Status: newclosed

In [17629]:

Fixed #17799 - Documented that the execute() method of a management command is not suitable for calling the command from code; call_command should be used instead. Thanks kacah222 for the report and claudep for the patch.

comment:5 by Ramiro Morales, 12 years ago

In [17678]:

Fixed #17820 -- Fixed more occurrences of redundant handling of management commands options.

They had been missen in the first attempts or had been introduced afterwards.

Refs #13760, #10080, #17799.

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