Hi,
I'm lead dev for Fabrik (an app builder extension). I'm writing a Komento integration.
The problem I've run into is that the assumption underlying integrations is that the app has a single "article" table like #__categries, or vm_products, or k2_items, etc. So the 'cid' field in the main Komento #__komento_comments table is an INT, essentially expecting it to be the primary key on the app's single "article" table.
In Fabrik, we don't have a single "article" table. Our equivalent of categories / articles are "lists" (arbitrary database tables) and "row ids" (PKs in the tables). And any given Fabrik app can have dozens of different lists. And of course the rowids of those lists (tables) are not unique - they are all auto-inc PKs starting at 1.
So for Fabrik to work with Komento, the 'cid' needs to hold two ids - the list and the rowid.
As far as I can tell, the only change that needs to be made in Komento for this to work is the 'cid' field in #__komento_comments table needs to be a VARCHAR, not a LARGEINT. That way, I can set the 'cid' in my item to listid:rowid (like 17:147), and my various KomentoComfabrik class methods like load() can just split out the two ids I need from that.
I've tested locally, changing 'cid' to VARCHAR(64), and it doesn't seem to adversely affect Komento at all, and my integration then works perfectly.
I know changing field types is not something we like doing as extension devs ... but I'm hoping you might put it on your list for things to consider.
-- hugh