Hi @ayesh!
Thanks for your digging on this.
Yes, the Wiki says. that atomfeed runs on the Events module, but actually it looks like that was never implemented. The Hibernate interceptor is basically identical across the two except that: in Events it uses the afterTransactionCompletion() event and checks that the transaction was completed before firing notifications, where in Atom-Feed, it uses the beforeTransationCompletion() event and seems to generate events regardless of if the transaction was committed or not (the change was made in this commit). This seems to have been related to some funkiness with accidentally creating a sub-transaction to store data in a the feed, but there’s a lot more in this Talk post. It appears that the future state Darius alluded to was never implemented. That might be worth reviving.
Questions:
-
Apparently, no. I still think having a single solution here is worthwhile, but apparently the event module could use some attention.
-
One of the advantages of using the events module and ActiveMQ is that we don’t have to implement custom queuing. I would think either migrating ActiveMQ in the events module to use the database for storage or building off the AtomFeed module are the right ways to address this.
-
AtomFeed’s main use-case (as I understand it) is for sharing data among the various components of Bahmni and as part of Sync 2.0. The classes excluded are probably not commonly shared via those interfaces (admittedly Order is a bit of a weird one).
-
Backwards compatibility? api-1.9 is only applicable when run in versions < 2.0.0; api-2.0 is applicable in versions > 2.0.0.