On Thu, Jul 23, 2009 at 11:55 PM, Adam Seering<aseer...@mit.edu> wrote:
>
> Hey folks,
> I have a PostgreSQL stored procedure that does some fairly complex
> logic to query/filter a particular table (though it ultimately does
> return rows straight from that table). I'm trying to call this stored
> procedure from within Django, and execute additional filters/etc on the
> procedure:
>
> MyModel.do_my_stored_procedure('proc', args).filter(mymodelfk__foo=bar)
>
> (or the like.) Anyone have any pointers on how to best do this? Is
> there, by any chance, native support for this in Django 1.1 that I just
> haven't found yet?
>
> There's an existing implementation that worked decently with Django 1.0
> (djangosnippets.org #272). However, it works by generating a normal
> query through an ordinary QuerySet and doing string
> matching/substitution to insert the function call. I'd like to do
> something a bit cleaner, but I don't yet understand Django's internals
> well enough to hack them this much... Any ideas?
There isn't a simple "run stored procedure" entry point in the Django
ORM. That said, it may be possible to do what you want, depending on
exactly how you want to use the stored procedure.
For example, if your stored procedure is a column-modifying function,
you can use a custom field definition to mutate the SQL - if you
define the get_db_prep_value(), you can modify the way a column is
rendered in SQL. DateFields give an example of how this is done (since
they need to convert Python Dates to SQL dates).
There are also a bunch of tricks, of varying degrees of complexity,
that can be played by defining a custom models.Query or
models.sql.Query class. The Oracle backend and contrib.gis both use
this technique to expose Oracle-specific and GIS specific query
features. These are some pretty big and hairy blocks of code to wrap
your head around; if you want specifics, ask a specific question and
I'll try to help.
The first step would be to state the SQL that you want to run as an
end goal - once I've got a clear idea of what you want to spit out, I
might be able to point you at the right places to look for hints.
Also - keep in mind that in some cases, the best solution is just
"don't use the ORM". Django's ORM isn't designed to be homomorphic
with SQL - it's designed to make simple and common object queries
easy. We have specifically avoided adding obvious SQL-like features to
Django's ORM, because at the end of the day, we're not trying to
replace SQL - we're just trying to provide a convenient way to express
simple queries. It is fully expected that you will fall back to just
calling raw SQL for complex cases.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
