Still a Servoy issue with DB UUID PK's

[rafig]

I’m creating a new topic for this, even though I could add something to previous posts as old post updates don’t seem to ‘surface’ as well in Developer notifications…

Many years ago I posted a long topic about this issue & it has happened again for me and is now getting to be a real PITA!

Servoy Issue with DB UUID PKs

this included me creating a support case

https://servoy-cloud.atlassian.net/browse/SVY-13551

that has been closed, but doesn’t seem to have been fixed/resolved.

[Developer 2025.6.2.4084, PostgreSQL server v14 local, v17 live server]

to quickly summarise again

1. I create a table structure directly in SQL that I run on PG Server

2. when opened in Server Developer, the ID column is identified as ‘DB Identity’

3. I change this in auto enter options to use db default (uuid_generate_v4()) and then ‘save’

3.5) in between above & below, when I look in GIT at changes to DBI, the auto enter type & sub types have been removed

4. I then change auto enter option to sequence - uuid generator and ’save’

5. (DBI file changes are then reverted as there doesn’t seem to be a difference between ‘uuid gen’ & ‘db ident’ ), but it is displaying as ‘uuid gen’

This solution is being deployed in the WAR/.servoy method (i.e. I export a WAR without solution & then can import new .servoy releases when needed.

This problem (finally) is that when I upload a new release to add something or fix something, even when ‘override’ solution import options ARE NOT SET, the new release when used fails to save new records because the wrong type of ID is being generated (it seems to be using the DB Ident type)!

So any time I make change that I need to upload, I have to go thru all the above steps 26 times as there are 26 tables using UUID generated PK’s! (and then set the override values)

I just tried putting the latest PG JDBC driver on my developer, no difference…

I also tried adding an extra dummy column to a table using Servoy, so it was updating DBI & might keep the right settings, no difference…

I also tried this with Servoy 2025.9, no difference…

As noted in my original, for that solution at the time I ended up creating a PG function/trigger to add UUID if it was ‘empty’, but I would like this solved/resolved, so don’t want to have to do that for this client (& various others as well that I use this way of creating my back-end for…)

Please advise??

Thanks

Rafi

[paul_bromwell]

Have you tried just not providing a default value on the column if you’re relying on Servoy’s UUID generator to make the values? Or is something else pumping data into this table besides Servoy?

CREATE TABLE fleet (
    id uuid PRIMARY KEY,
    -- ...
);

[rafig]

Hi Paul,

I haven’t tried that, but I’m sure that would work…

A lot of the tables have data imported in to them via external tools, so I needed the PK’s to be generated by PG as Servoy wasn’t ‘in control’.

But, also, it should not be such an issue even if the tables are not ‘pumped’ with data by something else…

Thanks

[paul_bromwell]

Could you have those external tools pump the data into another table, then run a Servoy method that copies them into the actual table with Servoy-generated UUIDs?

[rafig]

Thanks for the suggestion Paul, but I really want Servoy to try to fix this

(I know there are lots of ways around what you are referring to…)

Have a good weekend

Thanks

[jcompagner]

i really don’t get this setup
you should NOT do both, OR you let postgresql handle it. And servoy with inserts will not give the pk and then ask it back after insert what was generated
Or you let servoy generate it and don’t let postgresql do anything

There is a middle way if you want to force it, like you have to import data and the PK<->FK combination is already in the data.
This is fine with the UUID generator in servoy but it should also be fine with a uuid generator in postgresql.

for import you just make make sure the new records that you create has the uuids filled in then servoy will just send those.

So i am still not sure what the problem is, except that you need to chose a default generator and not have 2 of them. In both scenario’s you still are able to provide your own if you want to.