Bugger, the view approach won't work as the SQL query takes parameters. On Nov 14, 3:59 pm, Tomek <[EMAIL PROTECTED]> wrote: > Thanks for that. You just gave me a good idea. I could simply replace > that crazy SQL code with an equivalent view! This way I don't have to > write any nasty code to deal with old craziness. > > In the last 10 minutes I have looked again at django_restapi code and > I have discovered an example for dealing with resources which don't > map 1:1 to Django models. There might be some interesting ideas there > too. > > cheers, > -tomek > > On Nov 14, 3:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Wed, 2007-11-14 at 02:36 +0000, Tomek wrote: > > > Wow, what a quick reply! Thanks Malcolm. > > > > I'm pretty new to Django so excuse my inability to express myself in > > > Django terms. > > > > I agree with your comments regarding taking the right approach to > > > solving the problem (how very Pythonic of you :-) > > > I tried django_restapi because it offered a quick starting point for > > > some proof of concept prototypes which I am most likely to throw away > > > anyway. > > > > When I say that I want to create a model for a custom SQL query I mean > > > exactly that. I would like to have a model class which behaves just > > > like any other model but with some exceptions: > > > > - it would be read only > > > - there is no table corresponding to the model class > > > - when retrieving records/instances of the model a custom query is > > > executed instead of whatever query Django would generate > > > automatically. > > > A model represents the Python view of a table or a view at the database > > level, not the output of a custom SQL query (unless that query is a > > view). > > > If you want customisation beyond that level, you're no longer using > > Django's ORM, although you might be able to fake it with save() methods > > on your model and stuff like that. Wouldn't be the first project I ever > > undertook with Django, though. > > > Again, Django's ORM is designed to represent database tables (actually, > > it's designed to provide persistent storage for Python objects, but it > > happens to work in reverse, too). It turns out, since database views are > > like tables, we can handle views. If you want more customisation than > > that, it rapidly gets more fiddly. Not impossible, but harder. > > > So your approach sounds wrong to me. Instead of trying to force things > > into Django's ORM easily, you'll either need to spend some time > > understanding the deep internals or write your own objects that look a > > lot like models but aren't really models. > > > Malcolm > > > -- > > Borrow from a pessimist - they don't expect it > > back.http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
