Also, found the patch I
wrote: https://gist.github.com/jarshwah/a541857db195f0486b9e
Instead of multiple subclasses, perhaps Func could take on some of the
functionality of transform directly, but that makes no sense for > 1 arity
functions. A nice design should be able to be found.
On Thursda
Hi Mahmud,
On Tuesday 31 March 2015 16:17:52 mahmudul islam wrote:
> I am not sure about the current development branch but last time I checked,
> performing query on proxy models by default considers all the objects of
> the parent/base class. If anyone is to consider only the objects of that
> c
Hi all,
I've quite often found myself needing to pass custom kwargs to each form
within a formset (common parameter for all forms). A common pattern for
this is implementing a custom BaseMyModelFormSet(BaseModelFormSet),
overriding __init__ and then passing the custom argument via
_construct_f
That is correct - RunPython and some other operations (definitely
DeleteIndex) don't have single SQL statements that can be output. There's
not much that can be done here, really - if you want to use SQL to set up
databases, then you can't use RunPython to do it, you should just use
migrations dire
I am not sure about the current development branch but last time I checked,
performing query on proxy models by default considers all the objects of
the parent/base class. If anyone is to consider only the objects of that
class, he has to implement a custom modelmanager for that and use it. In
Not sure about this but wouldn't "RunPython" actually keep you from getting
an proven accurate result ? Even if we could imagine running the migration
in a transaction and capturing the SQL that would be run, it would be
dependent on the current data in the DB among other thing (could even be
d
