On Thursday 23 October 2014 06:14:19 Carl Meyer wrote:
> > On Oct 22, 2014, at 5:56 PM, Shai Berger wrote:
> >> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
> >>> On 10/21/2014 04:04 PM, Shai Berger wrote:
> >>> I'd argue that in the common case, the user shouldn't care if the
> >>> fun
I will happily cede ground to people who actually use stored procedures.
On 23 October 2014 04:14, Carl Meyer wrote:
>
> > On Oct 22, 2014, at 5:56 PM, Shai Berger wrote:
> >> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
> >>> On 10/21/2014 04:04 PM, Shai Berger wrote:
> >>> I'd argu
> On Oct 22, 2014, at 5:56 PM, Shai Berger wrote:
>> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
>>> On 10/21/2014 04:04 PM, Shai Berger wrote:
>>> I'd argue that in the common case, the user shouldn't care if the
>>> function they are calling is implemented in Python or Procedural SQ
On Wed, Oct 22, 2014 at 12:35 PM, Carl Meyer wrote:
> Here is where we differ. I think calling a database stored procedure is
> fundamentally a different thing from calling a Python function (even one
> that accesses the database), and the difference should be obvious in the
> calling code. I don
Hi Carl,
On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote:
> On 10/21/2014 04:04 PM, Shai Berger wrote:
> > I'd argue that in the common case, the user shouldn't care if the
> > function they are calling is implemented in Python or Procedural SQL
> > (assuming it is going to interact with th
Hi Shai,
On 10/21/2014 04:04 PM, Shai Berger wrote:
> On Monday 20 October 2014 21:26:50 Carl Meyer wrote:
>> Hi Marc,
>>
>> On 10/19/2014 12:54 AM, 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.
>>
Hi Chris,
On 10/22/2014 09:05 AM, Chris Foresman wrote:
> Good points. I went looking for `callproc()` documentation and couldn't
> find anything useful, which if I understand correctly is part of the
> reason this thread started. So +1 on documenting it!
>
> The most complicated part of dealing
Good points. I went looking for `callproc()` documentation and couldn't
find anything useful, which if I understand correctly is part of the reason
this thread started. So +1 on documenting it!
The most complicated part of dealing with store procedures from a high
level is getting them in the d
On Monday 20 October 2014 21:26:50 Carl Meyer wrote:
> Hi Marc,
>
> On 10/19/2014 12:54 AM, 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.
> >
> > However if we plan to make this a public API, it s
On Tuesday 21 October 2014 18:23:44 Chris Foresman wrote:
> Is there some benefit to using `.callproc()` over this?
>
> ``` python
> query = 'CALL sp_recommendation_engine(%s, %s)'
> profile = user.get_profile()
> cursor = connection.cursor()
> cursor.execute(query, [user.id, profi
Is there some benefit to using `.callproc()` over this?
``` python
query = 'CALL sp_recommendation_engine(%s, %s)'
profile = user.get_profile()
cursor = connection.cursor()
cursor.execute(query, [user.id, profile.id])
```
On Monday, October 20, 2014 1:29:49 PM UTC-5, Carl Meyer wr
On 10/20/2014 12:26 PM, Carl Meyer wrote:
> On 10/19/2014 12:54 AM, 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.
>>
>> However if we plan to make this a public API, it should be a nice one.
>> Someth
Hi Marc,
On 10/19/2014 12:54 AM, 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.
>
> However if we plan to make this a public API, it should be a nice one.
> Something along the lines of db.procedures.p
o be backend dependent.
>
> I can't think of a reason to deny cursor.callproc() the same status as
> cursor.execute().
>
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself
I was thinking in the context of a project - creating a procedure to use in
the code. Naturally cursor.execute() is perfectly fine for tests, which
would need to be backend dependent.
I can't think of a reason to deny cursor.callproc() the same status as
cursor.execute().
Marc
On 19 Oc
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 does
ts;
> some
> database drivers (notably cx_Oracle) allow passing also a dictionary of
> named
> arguments, so we want to support that too. While reviewing the PR, we found
> that
>
> (a) cursor.callproc is not documented
> (b) cursor.callproc is not tested (except for one Oracle-sp
3] to enhance this method -- the pep249
definition takes the procedure name and a list of positional arguments; some
database drivers (notably cx_Oracle) allow passing also a dictionary of named
arguments, so we want to support that too. While reviewing the PR, we found
that
(a) cursor.call
18 matches
Mail list logo
