[Question] how do you get django to recognize the dynamically created Event Models during makemigrations?

[simkimsia]

I don't understand how you do this.

I know the following:

1. Signal Handling in AppConfig: The class_prepared signal is connected to the pgh_setup function in the __init__ method of the PGHistoryConfig class. This ensures that as soon as a model class is prepared, the function pgh_setup is invoked.

   class_prepared.connect(pgh_setup)

2. pgh_setup Function: This function checks if the sender model (which is now prepared) has a pghistory_setup method and if so, calls it. The pghistory_setup method is where all the dynamic model creation and setup logic will likely be located.

   def pgh_setup(sender, **kwargs):
       if hasattr(sender, "pghistory_setup"):
           sender.pghistory_setup()

3. Event Model and pghistory_setup: This method, as a part of the Event model, does the actual setup, including adding triggers, creating the event model, etc. The model is then added to the app registry.

   @classmethod
   def pghistory_setup(cls):
       # Your setup logic here

Then i am lost. I still don't see how Django's makemigrations pick up the dynamically generated class. Because makemigrations is very strict abt looking for models in models.py.

In your docs at https://django-pghistory.readthedocs.io/en/3.0.0/event_tracking/#using-pghistorytrack you stated

Running python manage.py makemigrations will produce migrations for both the triggers and the event model.

Although event models aren't in models.py, they're still imported, migrated, and accessed like a normal model.

me: but how????????

UPDATE

I see that there's a create_event_model method

but you're accessing the tracked_model.__meta.fields and using methods like ._meta.get_field(field_name) how do you ensure that the model is properly loaded and you don't get errors like django.core.exceptions.FieldDoesNotExist

Also how do you prevent the eventmodel from facing clashes of the reverse accessor issue?

[wesleykendall]

I'm adding the model to the module here. Since this is added during loading of models.py, Django treats it just like any other model.

One annoyance with this approach is that type checkers and intellisense with IDEs won't recognize these models, but one can always directly create the model