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 <g...@thataddress.com> wrote:
> George Vilches wrote:
> > Russell Keith-Magee wrote:
> >> On 8/12/07, George Vilches <g...@thataddress.com> 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
