🐛 N°4992 - Handle parameters with same name in DBUnionSearch

[vbkunin]

Hi, @piRGoif ! Here is the Initial report and discussion on Sourceforge: DBUnionSearch object generates an SQL query using the parameters of only the first sub-search object.

[piRGoif]

Many thanks Vladimir ! Will have a look with @rquetiez and/or @eespie before planning this PR for review.

[piRGoif]

Hello, I had a look to the code with @eespie and this seems perfect to us ! We would like to add a phpunit test though... We can code it for you, as you already did a lot of the job. But just to be sure, did you checked the "Allow edits from maintainers" checkbox in this PR ?

[vbkunin]

Yes, "Allow edits by maintainers" is checked. I would appreciate your help with unit tests)

[piRGoif]

Ok thanks ! I'll have a look !

[piRGoif]

Hello, I'm really sorry, it took me a while to take a look. I just began writing a test, I saw your branch is based on support/2.7 (2d156bd7). I'll change this PR accordingly.

[piRGoif]

Test pushed ! PR is ready for next technical review (should happen next month)

[piRGoif]

Discussed during technical review : we'll have to deep dive into this, cause this might not be the better way to solve the issue. Actually the 2 DBSearch still exists in the UnionSearch instance, and this behavior shouldn't happen ? We might find a fix in the UnionSearch instead ? We will keep you posted !

[piRGoif]

Hello,

We took some time to discuss the issue with @rquetiez and @eespie Renaming the params is a workaround, this behavior is a real bug... We would like to dive deeper to understand what is its cause.

A simple PHPUnit method like this one :

		$oSearchA = new DBObjectSearch('UserRequest');
		$sParamVal1 = 'R-000001';
		$oSearchA->AddCondition('ref', $sParamVal1, '=');
		$oSearchB = new DBObjectSearch('UserRequest');
		$sParamVal2 = 'R-000002';
		$oSearchB->AddCondition('ref', $sParamVal2, '=');
		$oUnionSearch = new DBUnionSearch([$oSearchA, $oSearchB]);

		$sOql = $oUnionSearch->ToOQL(true);
		$this->assertContains($sParamVal1, $sOql);
		$this->assertContains($sParamVal2, $sOql);

		$sUnionSql = $oUnionSearch->MakeSelectQuery([], [], null, null, 0, 0, true);
		$this->assertContains($sParamVal1, $sUnionSql);
		$this->assertContains($sParamVal2, $sUnionSql);

Shows that the problem appears in the SQL generation : developed OQL is fine.

I'm going to do some debug step by step to locate specifically the cause. If it is fixable with not so much effort, we would prefer to fix the bug than implement a workaround ? We'll see if this is possible.