Bug 31142 - Don't generate object for depth > 1
Summary: Don't generate object for depth > 1
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Test Suite (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Chris Cormack
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-12 13:54 UTC by Jonathan Druart
Modified: 2023-06-08 22:26 UTC (History)
3 users (show)

See Also:
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 (11.11 KB, patch)
2022-07-12 13:56 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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)