On the other side of it, this could almost be done by simply creating a new base class which your view-based model could subclass, instead of models.Model. It could share much of the existing Model code, allowing for declarative syntax, adding in the default manager, processing Meta options, etc. It just wouldn't have the extra methods that would normally write to the database.
The reason I say "almost" is that the only way I can see to avoid syncdb processing is to skip the model registration, but that would then also cause it to disappear from the admin, which probably isn't what you want. Well, at any rate, if there is eventually a way to avoid having a table created for a model, you can in fact go this route if you'd really like to avoid having save/delete/etc on your models. Also keep in mind that you'd have to create a new default manager as well, in order to get rid of the create method. All that said, I agree with Malcolm on not bothering to remove create/save/delete. After all, trying to call them will raise an error regardless of whether they exist. Removing them would basically just swap out a DatabaseError for an AttributeError. Six of one, half-dozen of the other. -Gul --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
