chore: Allow only iterables for BaseDAO.delete()

[john-bodley]

SUMMARY

Previous—due to legacy reasons when we had both single and bulk delete logic—the BaseDAO.delete() method accepted either a single item or a list of items. For simplicity and clarity this PR updates the function signature to support only the later. i.e., it is now apparent from the code that deletion is a bulk operation.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

CI.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[giftig]

LGTM

[michael-s-molina]

@john-bodley I like the cleanup but isn't this a breaking change? What if someone is extending the BaseDAO to provide custom functionality?

[john-bodley]

@michael-s-molina couldn’t you extend that same logic for any change, i.e., in #25819 what if someone was referring to the old class? I guess it really depends on one’s interpretation of what’s public and in this case whether the intent is for DAOs to extended/leveraged in custom configurations.

[michael-s-molina]

@michael-s-molina couldn’t you extend that same logic for any change, i.e., in #25819 what if someone was referring to the old class?

The difference in this case is that tags are not officially released yet.

I guess it really depends on one’s interpretation of what’s public and in this case whether the intent is for DAOs to extended/leveraged in custom configurations.

I agree. Some parts are easy to identify as potential for breaking changes such as APIs or database engine specs. Other parts such as DAOs or form data are not so clear. Maybe we should bring this discussion to the Town Hall and formalize the constraints. @villebro @rusackas @betodealmeida @eschutho

[john-bodley]

@michael-s-molina per the recently added Semantic Versioning wiki page do you feel this is non-breaking and thus could be merged prior to the 3.1 branch cut?