On Wed, 2009-08-12 at 11:39 +0200, Thomas Guettler wrote: > Hi, > > I am writing a workflow engine. The base workflow is stored in the DB. > But some code needs to written for most workflows. > > This means I need code for a model instance (an not code per mode class). > > To make this most pythonic, how could this be done? > > My idea: since I want the workflow to be portable to several installations, I > don't use > serial IDs for primary keys, but slug-fields. The slug-field could be a > importable > classname like 'foo.workflow.MyClass'.
You already have the content type table for referring to other model objects. Why not use that so that you can maintain some referential integrity. I suspect, simply because you've been using Django forever and know what's going on, that there is something subtle here I don't understand, so feel free to tell me why I'm an idiot and this won't work. > > Now I want that the Workflow model instance inherits from MyClass. This must > be done at runtime. I think this could be done with a custom manager. This is where I become Old Conservative Malcolm and say that you might want to consider NOT abusing model inheritance! :) I have reasons, though, so let me explain... I try to always relate this back to Python and what you can do in Python with normal classes (Django's ORM just provides a way to store parts of classes on disk). You can do what you want in Python, using the type() command where you can create whatever base classes you like. Sadly, it's harder than that when we introduce the persistence part -- storing in the DB. Since inheritance is implemented via relations that are constraints at the DB level, allowing arbitrary tables is not going to be possible. Although I've tried to implement model inheritance so that it works as transparently as possible, there are limits and this is one of them -- it's a genuine leaky abstraction, because the database requirement influences the functionality regardless of what implementation I use. A Django relation that points to any type of model already exists, however: GenericForeignKey. Since you can ignore model inheritance in Django and use a OneToOneField to link the models, you can do the same thing with GenericForeignKey in the place of OneToOneField. So you end up storing the "type" of the remote model and the pk of the instance you are pointing to. No referential integrity at the database level there (although we do enforce that the type is an existing content type). Based on your brief description, I would use GenericForeignKeys here, I think. But please elaborate if there's a reason that won't work for you. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
