The "on duplicate" does not work in hsql DB, changed to "on conflict"

[Awwabsiddiqui]

A working example for HSQL DB compiler

-- create
CREATE TABLE ofPushServer (
    domain      VARCHAR(64)             NOT NULL,
    deviceId    VARCHAR(64)             NOT NULL,
    token       VARCHAR(1024)           NULL,
    node        VARCHAR(1024)           NULL,
    secret      VARCHAR(1024)           NULL,
    type        VARCHAR(16)             NOT NULL,
    CONSTRAINT ofPushServer_pk PRIMARY KEY (domain, deviceId)
);

-- insert
INSERT INTO ofPushServer(domain, deviceId, token, node, secret, type)
VALUES ('openfire', 'devid1', 'token1', 'node1', 'secret1', 'type1');

INSERT INTO ofPushServer(domain, deviceId, token, node, secret, type)
VALUES ('openfire', 'devid2', 'token2', 'node2', 'secret2', 'type2');

INSERT INTO ofPushServer(domain, deviceId, token, node, secret, type)
VALUES ('openfire', 'devid3', 'token3', 'node3', 'secret3', 'type3');

-- fetch 
SELECT * FROM ofPushServer;

INSERT INTO ofPushServer(domain, deviceId, token, node, secret, type)
VALUES ('openfire', 'devid2', 'tokenX', 'nodeX', 'secretX', 'typeX')
ON CONFLICT (domain, deviceId) DO UPDATE SET token='tokenX';

SELECT * FROM ofPushServer;

[guusdk]

Thanks! Can you confirm if, after this update, the code will be compatible with all other database systems that Openfire supports?

[Awwabsiddiqui]

Not yet.

I'll check all the databases and then write either a SQL function based logic (Try catch based), or change the query based on the DB used.

This is just the basic fix that I had to do while implementing a chat box in my organisation where I used postgre as well as HSQLDB and the implementation failed directly in both, resulting a direct error in the openfire logs itself.

[guusdk]

Some other plugins, like the Monitoring plugin, have code that use different SQL based on the type of database that is being used. Maybe you can get inspiration from there.

Alternatively, maybe the code can be rewritten so that it is compatible with all database servers (e.g. do a DELETE first, then an INSERT).

[Awwabsiddiqui]

Yes I've actually implemented the monitoring plugin and it works on the logic that you've said and we could probably use that as well (but that'd be a hail mary because it requires major codebase changes, and would probably require more changes in the future if another DB is added.)

I'll first check if the conflict logic works in all the DBs.
If not, I'd probably go with a faster friendly approach.

Also, on a separate note, I haven't actually been able to send a Firebase notification using the plugin (even after the logs say that it's delivered : PushInterceptor.java:L275).
Are we sure that we've implemented the new Google Auth changes that require a refresh token every 1 hour, and only then does it allow to push a message ? (I implemented this organisation wide, without which none of our services could send a FCM message.(Used a fast streamlined recursive approach as well.))

[guusdk]

Are we sure that we've implemented the new Google Auth changes

I functionally know very little about what this plugin is supposed to do. I don't think it has been updated in a while, so if there are new restrictions, then it may very well be the case that those have not yet been implemented here. Hopefully the original authors
@hamzaozturk @haknsahn can help you with that!

[Awwabsiddiqui]

According to my RnD, the previously implemented "ON DUPLICATE" works
only with MySQL DB (this was probably the DB used when developing the
plugin).
The updated "ON CONFLICT" query works in all major DBs, except for
MySQL.

However, the default DB for OpenFire (HSQL DB) supports neither of them.

We can either change the query according to the DB(as suggested), or
provide this implementation.

Try/Catch or a case based SQL approach does not wok in DML of any SQL,
hence a count query would be more appropriate.

Also, I do not know kotlin and would very much appreciate any input in
optimizing the code if possible.

Note: With this approach, we can effectively remove the unique constraint on the table as it would merely be a precaution with time overhead.