Project

General

Profile

Bug #10049

UDF configuration regression in Persistence.java

Added by Ovidiu Maxiniuc about 1 year ago. Updated about 1 year ago.

Status:
Test
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
Constantin Asofiei
production:
No
env_name:
topics:

History

#1 Updated by Ovidiu Maxiniuc about 1 year ago

  • Status changed from New to Internal Test
  • % Done changed from 0 to 100

Constantin noticed a flaw in the configuration of UDF (SQL native vs deprecated Java). Just by chance, I identified the same issue and put the fix in another branch, for a more complex task.

The goal of this task is to have a branch for a fast-lane merge of the fix into the trunk and, by using using rebase operation, Constantin will pick the the change into his working branch.

I created task branch 10049a from latest trunk and committed the fix as r15942.

#2 Updated by Ovidiu Maxiniuc about 1 year ago

  • Status changed from Internal Test to Review

Constantin, please review the fix since it is a bit different (I rewrote 4 lines to be more human readable) than what you proposed.

#3 Updated by Constantin Asofiei about 1 year ago

I'm OK with the changes.

#4 Updated by Ovidiu Maxiniuc about 1 year ago

  • Status changed from Review to Internal Test

OK, then I am putting this to the test.

This area is accessed each time a Persistence object is initialized. There are two cases: for permanent tables (cfg is available) and temp-tables (cfg is null). A unit-tests for a large application will certainly cover both cases. I will also use the harness test from other customer to make sure there are no issues with tenants. I will report the result as soon as both of them are available.

#5 Updated by Ovidiu Maxiniuc about 1 year ago

The aforementioned test passed.

#6 Updated by Eric Faulhaber about 1 year ago

This is only a runtime change, with no new UDF installation (or other special handling/configuration or devops) required, correct?

If the answer is "no", we need to communicate any breaking change or special instructions to each customer this affects, before we push it into trunk, per #10044.

#7 Updated by Ovidiu Maxiniuc about 1 year ago

There is no new UDF added. Only a small runtime change.

As noted in first note, the problem was an incorrect detection of whether the native UDFs are in use or the old/deprecated Java UDFs. The latter were incorrectly chosen.

#8 Updated by Greg Shah about 1 year ago

  • Project changed from Bugs to Database

#9 Updated by Constantin Asofiei about 1 year ago

  • Status changed from Internal Test to Merge Pending

Please merge 10049a now.

#10 Updated by Ovidiu Maxiniuc about 1 year ago

  • Status changed from Merge Pending to Test

Branch 10049a was merged into trunk as rev. 15946 and archived.

#11 Updated by Roger Borrello about 1 year ago

I am a little concerned with how Hotel GUI has changed. I have been enabling the capability to modify the password for fwd_admin and fwd_user via the command-line of prepare_dir.sh as well as through the environment space in a Docker container. I noticed the significant change to build.properties, including the changing of the sql.user.pass and sql.admin.pass from user and admin respectively, to fwd_password for both.

Was that an intended change? It could be that I just don't understand the changes to the MT methods, including the addition of SQL Server. I was going to test my changes against the standard Hotel GUI, but found that things had changed.

#12 Updated by Ovidiu Maxiniuc about 1 year ago

No intention. Sorry. Reverted back to old values.

#13 Updated by Roger Borrello about 1 year ago

Ovidiu Maxiniuc wrote:

No intention. Sorry. Reverted back to old values.

Thank you!

Also available in: Atom PDF