Hello @all, sorry for the cryptic subject but summarizing what this mail is about, is kind of hard. :) So please bear with me for a moment...
I am working on an application that is designed to be highly modular and extendable (by means of plugins). So basically you have models that are stripped down to a bare minimum of data and behavior (the common set) while the rest can come in via plugins. For example: An admin creates instances of a model through the admin. Some require just the basics but others do require special behavior and some extra data, thus he adds plugins to those. What jumps to mind is model inheritance for the plugins. But since it is unforeseeable how many plugins an installation will have and how many a specific model instance will have attached to it or what kind of plugins (since the plugin system is heterogenous), performance is a great concern of mine. Each time a model is utilized for a site's visitor, every plugin needs to get evaluated. Thus I want to make sure that I get everything for a model with 1 query instead of several. This naturally can result in quite a lot of joins, actually at least O(N) (with N being the number of plugins that the system has installed for a specific model type). This alone worries me about the scalability and feasibility of such a system. So I'd like to ask the community for advice if my concerns are justified and if this is a sound approach? By the way, after having implemented my own solution, I came across the InheritanceManager from django-model-utils which is what is used now for the downcasting part (if that matters). Right now I am also thinking about possible alternatives without loosing the flexibility of the plugin system itself (which is a necessity): Instead of saving each plugin to its own table, the plugin system could be designed to utilize just one table with all the common plugin meta data saved as columns and the rest is being serialized to JSON and saved as such in another column. Thus, one could very easily get all plugins for a model and only had to construct the plugin model manually with the serialized data. This would work just fine with heterogenous and homogenous plugins. Naturally a plugin (and the overall system) looses some options when it comes to querying the database for specifics of a plugin's serialized data. Also there are ACID constraints like not being able to atomically increment a single field. But those limitations would be fine and could also be overcome if a plugin required it (by means of a dedicated data model for example). Again, I'd kindly ask for advice if this would be a more scalable approach compared to my initial solution above or if this is something that just stinks of problems and should be avoided at all costs? ;) Thanks in advance for any help and hints in advance. It is very much appreciated... So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu services: custom software [desktop, mobile, web], server administration -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/529EFF22.2070903%40binary-island.eu. For more options, visit https://groups.google.com/groups/opt_out.
