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 -~----------~----~----~----~------~----~------~--~---
