Bug 31142

Summary: Don't generate object for depth > 1
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: Test SuiteAssignee: Chris Cormack <chris>
Status: CLOSED INVALID QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: m.de.rooy, martin.renvoize, tomascohen
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Bug 31142: Don't generate objects if more than 1 level deep

Description Jonathan Druart 2022-07-12 13:54:18 UTC
We shouldn't need to generate objects the is more than one level deep in the structure.
For instance if we generate a patron, then the library, we certainly don't need to generate the SMTP server.
Comment 1 Jonathan Druart 2022-07-12 13:56:10 UTC
Created attachment 137633 [details] [review]
Bug 31142: Don't generate objects if more than 1 level deep
Comment 2 Jonathan Druart 2022-07-12 13:57:58 UTC
Spoiler: this does not work.

For the example in comment 0: SMTP servers are not generate anyway (not a 1-n relationship but n-n and so it's not generated by TestBuilder).

For t/db_dependent/Circulation.t we are passing from 502 objects to 504, no gain expected.

The change in the DB structure looks correct however.
Comment 3 Marcel de Rooy 2022-08-15 12:42:23 UTC
(In reply to Jonathan Druart from comment #0)
> We shouldn't need to generate objects the is more than one level deep in the
> structure.
> For instance if we generate a patron, then the library, we certainly don't
> need to generate the SMTP server.

I am not sure if this is always true.
Even in our tests we may generate objects in the assumption that the underlying object is created too, be it on level 1 or deeper.
If the object is optional, I would assume that I can set the FK to NULL and not create that object on the next level.
Comment 4 Jonathan Druart 2022-08-16 05:42:08 UTC
Yes, most of our 1-N are NOT NULL anyway.

The DB changes could be retrieved however (FK NOT NULL should not have a DEFAULT)