Hi Marc and all, On Sunday 19 October 2014 09:54:39 Marc Tamlyn wrote: > I guess now with migrations we have a nice way of running the SQL against > the database to create the stored procedures. > I'm not sure RunSQL is much preferable to cursor.execute() in this context. And either way, it doesn't solve the basic issue: The SQL to run would still differ between backends, so tests would still need to be backend-specific.
> However if we plan to make this a public API, it should be a nice one. > Something along the lines of db.procedures.proc_name(*args, **kwargs) would > be preferable I think. Obviously this requires more magic to make it work > (or explicit registration of your procedures). > That would be a very nice API indeed, but it is much higher-level than the one under discussion. At issue is a callproc() that implements pep 249, much like its siblings execute(), fetchone() etc; that is why I am not even suggesting to modify it to the obvious callproc(procname, *args, **kwargs). Cursor.execute() is documented, public API -- are there reasons to deny callproc() the same status? Shai. > On 19 October 2014 00:25, Shai Berger <[email protected]> wrote: > > > > [1] http://legacy.python.org/dev/peps/pep-0249/#callproc > > [2] https://code.djangoproject.com/ticket/23546 > > [3] https://github.com/django/django/pull/3342 > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201410200012.08958.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
