Hello!I have an app that uses the User object as a ForeignKey, and as a ManytoMany field. I am integrating this app into a project that doesn't use django authentication, and doesn't have a User object that is a model.
My first idea was to just store the User's uid in the database as a string, and have my views instantiate the objects. This can get kind of ugly for replacing the ManytoMany field. A similar solution would be to pickle the objects, and store them in a textfield. It can still get kind of ugly compared to the ManytoMany field.
I'd prefer to explore other solutions-- I don't want to rewrite all the logic in the app.
I'd still like to be able to retain the model.members.Objects.all() behavior-- At least something I can iterate over. Other behaviors of the ORM are nice too. I don't have to retain absolutely everything. Mostly just very simple features.
The only way I can think of that would possibly do that would probably be to write my own field class that doesn't use the database backend. It'd have to be taylored specifically to this type of user object. The app probably wouldn't care as long as it gets what it needs from this custom field.
My question is this:Given the limitations I've stated, what is the best solution? Is my first, ugly, solution the way to go? why? Is my second custom field solution the way to go? why? Do you have another solution?
If you hijack this thread by telling me to just use the django user object, ask why I have to use this other authentication system, or in any other way lead the thread off-topic, I will be forced to slap you with a live trout.
I appreciate the input! Thanks! Jeff Anderson
signature.asc
Description: OpenPGP digital signature
