Should we explore the idea that django-fsm-log should provide only Abstract Models ?

[ticosax]

Based on issues raised in #132 and #34, it seems there is a conflict in the ownership of the StateLog model definition.
Based on some projects, the type of the autofield can differ from project to project.
It is currently technically challenging to let projects redefining part of the StateLog definition, and in particular, about the id field.

One idea I would like to explore, is the following: What if django-fsm-log would become stateless ?
By that I mean, this lib would provide an AbstractModel and a set of utilities only. It would be up for the adopting project to define their concrete model, By doing so, we would explicitly leave the ownership on the Model and migrations to the adopting project.

Is it technically feasible ?
Do we know other projects who adopted this pattern ?

I would like to collect feedback on this idea.
Thanks.

[ddahan]

I don't have lots of experience about this, but from what you described, i can't see why it would not be feasible.
However, in term of deployment of the "new system with existing users, it may be a little more tedious, because of breaking changes.
I think we should not force existing users to use the new abstract model.

I have two ideas to avoid this:

• Fork this project -> no breaking change, but will force to maintain two projects that are closely related (more work)
  or
• Keep a single project but let the two ways to do it (abstract or not) -> avoid the breaking change for existing user, but creates a choice for newcomers, which need to be documented. If not, it could be confusing.

[ticosax]

We will keep the concrete model to keep backward compatibility only. as they are today.