Add: BigIntegerField and UUIDField -based CRUDEvents

[dkgitdev]

I've added those to use the library with personal projects of mine. Also, you can include the following markdown into the wiki:

• DJANGO_EASY_AUDIT_REGISTERED_CLASSES_FOR_BIGINTEGER

  A list of models, to be used with BigIntegerField as object_id. Deafaults to []

• DJANGO_EASY_AUDIT_REGISTERED_CLASSES_FOR_UUID

  A list of models, to be used with UUIDField as object_id. Deafaults to []

[jheld]

I'd rather everyone just get this going forward. Make it a required change to the models. Any reason not to do that?

[jheld]

@dkgitdev any feedback on this?

[dkgitdev]

I think that you're right. Explicit subclassing of the available models with abstract ID field should be clear way to make it flexible enough. I guess we should leave the default models as is and add some super class, so it can be subclassed to get the flexibility one's might need

[jheld]

I think that's an OK solution but I do wonder why don't we make the change explicit so everyone just gets it? what are the pros/cons for not subclassing?

[jsoa]

@dkgitdev @jheld changing the current CRUDEvent object_id to a charfield should address this issue in a more generic way, without the need of specific subclasses and to protect us from possible future cases of other types of primary keys. Thoughts?

[jheld]

Closing since we have an implementation from @jsoa on #138 . We plan to release officially soon! We've just landed support for django 3.1 & ASGI (for middleware sync support and wsgi & asgi request event signal support), so that holds us back a little from release, but once we get some feedback/stability, we'll release 1.3.0 officially.