pfouque
Do we need to Integrate a logging solution
Dedicated thread for the discussion started in django-fsm-log issue
Would it make sense to integrate a logging solution (probably as an opt-in contrib) into this project?
- Current fsm-log doesn't work with UUID primary keys (but the solution already exists: https://github.com/jazzband/django-fsm-log/pull/176 )
- There is already a dependency between django-fsm-admin and django-fsm-log : https://github.com/gadventures/django-fsm-admin/blob/master/fsm_admin/mixins.py#L168-L178
- a single package would be easier to setup for the users
- a single repository would be easier to maintain as a team
- All these libraries look feature-full, stable and have a clear scope
What do you think?
@pfouque what can I do to assist in making this happen? We use django-fsm heavily and are transitioning to django-fsm-2. I can't think of a single project of ours that does not make sure of django-fsm-log and django-fsm-admin
Thats a damn good question! 😅 It's a too formidable opportunity to not take the time to sit and think. We can imagine multiple strategies, but I guess the first one is to investigate to define the goal and a scope, and,if necessary, challenge some decisions that were taken.
Some questions I can think of:
- For example, I was unable to use this library because of the incompatibility with UUIDs as pk. This point is partially solved by @ticosax 's PR, if you use the same type of PK for the whole project.
- I was also wondering if a single table for the whole project is the way to go, or if one statelog per model would be better?
- Does django-fsm-log implementation would be the same if we can update django-fsm code?
In the end, IMO we should not aim for a fast integration, but for a solid one. Migration will be a challenge anyway!
Hi @pfouque,
Yes, I totally agree that thoroughly thinking this through will lead to a much more successful outcome. The old adage "An ounce of prevention is worth a pound of cure" definitely applies here.
My initial primary goal would be to integrate django-fsm-log. The steps to migrate should be as close to "drop-in" as possible, ideally by just swapping out the package and keeping the imports the same. This would make transitioning to the integrated logging package as smooth as possible, given its current feature set.
I think outstanding issues like UUIDs as primary keys and the question of transitioning to multiple state log tables per module should be a second phase. Those changes are likely to require people to modify their codebases. Providing a smooth transition to the integrated FSM log module will make updating easier for folks, so I'd definitely leave these more involved changes for a later phase.
I'm also curious about the benefits of having multiple state logs—with one state log table per module. Other than eliminating the need for GenericForeignKey, I don't see much of a benefit. Some of our applications display logs to show user activity over the past X days. Multiple tables would require us to union those tables together, which seems more complex. However, I might be missing key benefits that multiple tables would grant us.
I do wish that the Statelog had the ability to persist structured data in a JSON blob. This would let us include additional information like primary keys to objects or URLs. For example, I'd use it to pre-build URLs to link a log message directly to an object or another action. The JSON blob would persist simple data types and wouldn't serialize Python objects, similar to Django Celery Results' args, kwargs, and result fields. However, this is more of a feature enhancement and probably better left for the future. I could see this implemented as a core feature, or if it's deemed not necessary, we could offer the ability for folks to swap in their own custom Statelog model (as discussed in issue #176) and adjust the fsm-log methods and decorators to process additional arguments and keyword arguments.
My initial primary goal would be to integrate
django-fsm-log. The steps to migrate should be as close to "drop-in" as possible, ideally by just swapping out the package and keeping the imports the same. This would make transitioning to the integrated logging package as smooth as possible, given its current feature set.
What would be the benefits (assuming original fsm-log finally get released with the proper dependency) to make the transition easy but the next release upgrade a challenge?
I think outstanding issues like UUIDs as primary keys and the question of transitioning to multiple state log tables per module should be a second phase. Those changes are likely to require people to modify their codebases. Providing a smooth transition to the integrated FSM log module will make updating easier for folks, so I'd definitely leave these more involved changes for a later phase.
IMO it's easier to enforce a tricky migration on a library switch than on a version upgrade ( mostly automatic nowadays). Indeed it will be slower to adopt but if the benefits are clear enough it shouldn't be an issue.
I'm also curious about the benefits of having multiple state logs—with one state log table per module. Other than eliminating the need for
GenericForeignKey, I don't see much of a benefit. Some of our applications display logs to show user activity over the past X days. Multiple tables would require us to union those tables together, which seems more complex. However, I might be missing key benefits that multiple tables would grant us.
Currently, even with a "Bring you own model" approach, it will not be possible to use this library if your project use multiple type of primary keys (Some projects I worked on were using uuids for public models, but int for private ones).
I do wish that the Statelog had the ability to persist structured data in a JSON blob. This would let us include additional information like primary keys to objects or URLs. For example, I'd use it to pre-build URLs to link a log message directly to an object or another action. The JSON blob would persist simple data types and wouldn't serialize Python objects, similar to Django Celery Results' args, kwargs, and result fields. However, this is more of a feature enhancement and probably better left for the future. I could see this implemented as a core feature, or if it's deemed not necessary, we could offer the ability for folks to swap in their own custom
Statelogmodel (as discussed in issue #176) and adjust the fsm-log methods and decorators to process additional arguments and keyword arguments.
That could be a good feature indeed (I could have used it in my previous project)! Why don't you suggest/contribute it to the original project? It would be a good usecase (especially to see if it would require some changes in the fsm code to make it easier)
As we are, most likely, going to break backward compatibility, I believe we will have a better chance to succeed in terms of managing expectations, if we provide a new API within django-fsm-2 and leave django-fsm-log as the backward compatible version (assuming we can release). I don't think postponing the breaking path, will do any good when users are already using the lib (django-fsm-2). It will also offer us time to iterate and experiment until we find an efficient migration path from django-fsm-log to django-fsm-2. Designing bring your own model without care for backward compatibility is much easier to do. I have the intuition we could make a first iteration, where we develop a strong proposal for it. Then, in a second time, we could think about facilitating the migration with a collection of docs and utils.
It's great that we are collecting ideas on how we can make the bring your own model more future proof.
- Ability to choose a different TransitionLog per user defined criteria (TBD)
- json payload
I would add:
- DRF integration maybe ?
@ticosax Could you share more about DRF integration? I don't want to make assumptions, but is it something akin to this package?
https://github.com/27medkamal/djangorestframework-fsm