On Jan 26, 4:14 pm, bvdb <[email protected]> wrote: > On Jan 26, 3:22 am, Russell Keith-Magee <[email protected]> > wrote: > > > Django doesn't have a built-in representation of a view. .. > > > You can define a Django model as a wrapper around a view by marking it > > managed, but that doesn't make the model read-only -- it just prevents > > Django from trying to create the model during syncdb. > > Ok, thanks for this clear answer. > I've noted the "managed" option that might avoid errors on a sync but > as django still thinks these tables are updateable it's not a real > solution - and it's not wise to recommend django for the situations > mentioned in my first post. > > So the django ORM is in the same situation as the Ruby-on-Rails ORM. > But, as opposed to Ruby, a possible solution already exists in the > form of SQLalchemy. > This approach has already been > followed:http://code.google.com/p/django-sqlalchemy/ > > Progress in this project seems a bit low, but maybe one day some > enlighted ghosts will take up the torch ...
I am curious to know exactly what behavior you are looking for. Presumably you would want the standard ORM behavior as far as Read operations are concerned. It would seem to me that for Create, Update, and Delete operations, the possibilities are: 1. run-time error from the interpreter (method doesn't even exist) 2. run-time error from the framework (method disallowed) 3. run-time error from the db (view is read-only) 4. no-op (method exists, silently does nothing) The solution Russell Keith-Magee suggested would give you #2, but I imagine you wouldn't want that because it involved hitting the db unnecessarily. On the other hand, how often do you expect this to actually occur in production? With George Silva's suggestion, you could get #4 or #2, though you'd might have to override more than save(), you might want to change save.alters_data to False. You'd probably also want to subclass the QuerySet and override all the data modifying methods. Then subclass the model Manager and override its get_query_set to return an instance of your ReadOnlyQuerySet. If, as your original post indicated, your main concern is the admin interface, then obviously none of the above are acceptable, because your UI will contain elements that either cause server errors or don't do anything. I haven't looked at the the django-sqlalchemy project, so I don't know if that project addresses this issue, but obviously just using an ORM which provides read-only models won't change the fact that there's no read-only admin. I haven't tried this, but if you are using Django 1.2, you could probably make a read-only admin interface fairly easily: 1. See Chris Matthews' suggestion for removing the delete action 2. Supply your own admin template which won't include 'add' or 'save' buttons if the model is marked read-only 3 Subclass ModelAdmin and set readonly_fields to automatically include all fields on the model. Regards, Aryeh Leib Taurog -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. 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.
