UUID Generation PK Empty On New Record 2020.06

[joe26]

Hi guys,

** heavily edited **

When creating a new record for a table in 2020.06 Server, the PK (row id PK, uuid generator) is empty. I have the UUID set in 2020.06 Developer under which it works, as well as earlier 7.4.8. In each case, I'm using postgrestql 9.5. Preferences set to UUID Generator, UUID length 36).

When deployed to the server, it isn't generating the UUID primary key for the new record. Have not located the reason for this yet. This is both on the Dev side (servoy server) and deployed (application) side.

The webstart is pulling in the java Using JRE version 1.8.0_261-b12 Java HotSpot(TM) 64-Bit Server VM. I've installed the same jdk as Developer but it isn't linking to it, no webstart there. Setting the new record's PK to application.getUUID() works however. The UUID Generation for new records identified in the database table editor doesn't seem to function when deployed.

There is a prior posting, but https://forum.servoy.com/viewtopic.php?f=8&t=22433&p=119700&hilit=uuid+generator#p119700 seems related to raw sql.

From 2019.09 release notes: Support for native UUIDs if the database has that support (currently only postgresql and sql server), Table Editor now gives you that option.
A preference is added to the preferences to say what the default should be used for UUIDs, a string of byte column

From 2020.09 release notes: When making new tables with uuid pk columns the default will now be DB Native (UUID) when that is supported (Postgresql and SQLServer), this can be changed in the preferences.

However, these are existing tables, and function as intended from Developer, so cannot export that behavior into the .servoy import file.

And, are there Server-only Servoy distributions? They are mentioned in the Wiki, but I've only located one such installer.

thanks,
--Joe.

[jcompagner]

is the table already there when deployed? or was servoy making it at that time?

There as a problem with we loosing the uuid flag for specific scenario's which is fixed for 2020.09_rc can you test if it works for that release?

There is not a server only distribution because the way to make a distribution is to generate a WAR from developer (or command line) which is then the deployment.

Or use it the old way and only copy the application_server dir from a installation. (only for web or smart clients)

[joe26]

The table exists already. I'm updating to the lastest RC.

The RC2 seems to have resolved the error, but the process from going from one rev to another is vague. Well, not vague, but cumbersome.

Reviewing the possible distribution solutions .war versus .servoy. We've been using .servoy. Will follow with questions after review.

thanks,
--Joe.

[joe26]

After internally upgrading Developer and Server, getting an Cannot Load Application error.

SEVERE: Could not find login(module) solution 'servoySecurityLogin' for 'STS3'
com.servoy.j2db.persistence.RepositoryException: Could not find login(module) solution 'servoySecurityLogin' for 'STS3'

Checking to see if the linkage is broken. The module exists in the solution as well as appearing in the Solutions list.

Went back to 2020.06 Directory that held the working Application Server, sans the UUID Problem. Lost the login solution in 2020.09.

--Joe.

[jcompagner]

how are you exporting the solutions?
just all as active?
or do you also still use .servoy files that you import?

Do you have something reproducible so we can have a look?

That error that you give that is a smart client webstart console error or something that you see in the server log?

[joe26]

Exported as .servoy into an application server.

Not sure what 'all as active' means, unless it means that exporting the module isn't checked. It is checked.

The error is from a smart client webstart java console message.

The web client works correctly.

[joe26]

Went back to 2020.06.1 since this, at least, launches. Still a UUID issue on newRecord creation where the uuid generator isn't functional.

Both are resident actually.

Neither are licensed at the moment since just trying to upgrade to the latest.

Is there a link to which I need to attend that ensures UUID generation for new records besides setting 'Sequence Type?"

[jcompagner]

we can't directly reproduce this
i added a small solution that has a login solution and that seems working fine, so what are we doing differently?

[joe26]

Works on this side, too.

The login solution is based on the Servoy Security on ServoyForge, but cannot remember the password to load the original test solution.

[jcompagner]

so do you have a simple solution with that login solution where we can see this going wrong?
(so a .servoy file with a solution and and a module where we can see this going wrong)
i guess we don't need much else because it is going wrong very soon at startup i guess..

[jcompagner]

ok i found the issue and created a case:
https://support.servoy.com/browse/SVY-15474

the problem is that the login solution has the authenticator solution as module, which is a bit weird (because the login solution is one that can always be loaded and a authenticator can never be loaded in a smart client)
But i fixed this for the final of 2020.09, you can test this over a 2020.9_rc2 install by using this update.zip: https://build.servoy.com/latest/servoy_ ... update.zip

[joe26]

Ok. thank you. I will check it.

[joe26]

Thanks, Johan. That fixed the issue with login and authenticator.

I'm back to the UUID missing on a newRecord. This is likely from an empty Query Builder-based foundset, where a new record is created from that foundset.

I read somewhere in the Servoy Release Notes that QB is a little tighter. For now, and to continue testing, I just get a new UUID. Need to see if it breaks anywhere else, so that maybe I can locate a pattern.

[joe26]

Just a follow-up, in every case, the UUID was failing, even in Developer. Not sure why it eventually created the UUID but the missing UUID was apparent in some test code, although Developer was still not exhibiting the missing UUID.

The solution, having been moved from 7.4.8, was the original table structure. The fix seems to be adding a column to the tables upon conversion. So far only dealt with a single column. This action may force Servoy to modify the table and activates the UUID creation.

[jcompagner]

how do you export stuff? is this table touched by a form, valuelist or relation?
or is that table only used purely in scripting?
because if you use it purely in scripting really make sure that the export option has "export all tables of the selected servers" so that the column information is passed over to the server.