This sounds like a far more complicated example than I had considered when I was doing my work with dynamic models[1], but I did have success getting syncdb to install dynamic models, provided a few things are in order. I probably didn't document them well enough on the wiki, but I could do so if this is a real need you have.
I also can't speak for how well your audit example would work on the whole using that method, but if it's a real task for somebody, I'd love to help work it out. In theory though, given my past experience, it would be possible to do in such a way that a single line in each audit-enabled model would trigger all the hard work, enabling syncdb and even admin integration. Keep in mind that I have no opinion on the real meat of this thread, I'm just chiming in to help clarify what is and isn't possible with dynamic models. -Gul [1] http://code.djangoproject.com/wiki/DynamicModels On 8/14/07, George Vilches <[EMAIL PROTECTED]> wrote: > > George Vilches wrote: > > Russell Keith-Magee wrote: > >> On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: > >>> 1) Add a signal to every option? > >> If we were going to go down this path, this would be the preferred > >> option. However, I'm not sure I'm convinced of the need. Which > >> commands exactly do you think require signals? > > > > Since the first example I gave may not be particularly compelling, since > some craftiness with static Django models could be used to solve the > problem, let me give one that I don't believe could be solved that way. > > Assume I'm building a row-based audit system. I also want this audit > system to have one audit table/model per legitimate Django model. So, > say I have an app.model called "wiki.article". This would create a > "wiki_article" table. I also want to have a "wiki_article_audit" table > keeping a full history of changes. Now, since Django models don't > support inheritance yet, and I don't want to have to re-create every > model that I want to perform an audit on, I can instead create a dynamic > model from the original model with a small helper. Unfortunately, > syncdb and the like don't have a way of detecting this dynamic model and > creating tables and such for it. However, I've already got a mechanism > in syncdb (via signals) which uses the existing management functions to > write that new dynamic model to the database, and then in runtime > everything works perfectly happy. > > Unfortunately, since there's only a syncdb signal, I can't even do > things like a reset on it, and there's definitely no way currently to > get the SQL generated from my syncdb signal. Being able to get the > CREATE and DROP statements in text as well as each individually would be > a huge boon to this type of use (and any dynamic model use in general). > > Is that a more reasonable example? > > Thanks, > George > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
