Abstract base class for Model classes

[Ryan J Ollos]

An abstract base class for model classes is proposed for discussion. This was previously mentioned in #11609 and #11648. At a minimum we can discuss the challenges in making the API consistent for Model classes and perhaps improve some minor issues, even if we don't end up implementing an abstract base class.

[Ryan J Ollos]

I created this ticket because I wanted to look at this ahead of changes to Component and Version models in #1233.

[Ryan J Ollos]

One API inconsistency we may want to fix is the return value from select class methods. In most cases a generator is returned, but there are cases of a list being returned:

• trunk/trac/ticket/model.py@13060:1137#L1128​
• trunk/trac/ticket/model.py@13060:1234#L1222​

I suppose the difference is that the two method with return sort the list, but it seem ideal to always return a generator for consistency.

[Ryan J Ollos]

The Bloodhound ModelBase class (mentioned in comment:1:ticket:11609, [bh:browser:/trunk/bloodhound_dashboard/bhdashboard/model.py@1570461:44#L44]), has some useful aspects that we may want to adopt. For example, one obstacle to having a common signature for the select method for all the model classes is the include_completed​ parameter of Milestone class (though there are many other obstacles as well, and going too far down this path might just lead to the changes suggested by GenericTrac). The include_completed and similar parameters would be handled more generally by ModelBase with where, limit and order_by parameters: [bh:browser:/trunk/bloodhound_dashboard/bhdashboard/model.py?rev=1570461&marks=250#L249].

[Ryan J Ollos]

I've added some text to TracDev/ScratchPad/DataModels@2. Closing this for now as wontfix.