[Dbix-class] Operator Overloads in DBIC?

[Peter Rabbitson]

On 03/07/2016 01:25 PM, Paul Bennett wrote:
> Hi, DBICers,
>
> I have most of a spec (and a tiny bit of pseudocode) prepared for
> adding operator overloads to Result Sets, to make it easier to write &
> reuse pieces of queries in a style more like Relational Algebra &
> Tuple-Relational Calculus. For instance, '/' for relational division,
> '*' for fiber product, 'x' for explicit cross join, '|' for left
> semijoin, '||' for left outer join, '.' for full outer join, '>' for
> left antijoin, '+' for union, '&' for intersection, '-' for "except",
> and so on.

This is an interesting experiment. It is especially intriguing how the 
above will deal with corner cases of non-trivial-selection resultsets.

Please continue pursuing this ;)

>
> The path of least resistance seems to be to subclass ResultSet and
> some other classes.

Generally given your objective you'd need to subclass ResultSet *only*. 
If you end up needing more - it is likely your overall design is 
lacking, and you are strongly encouraged to seek further assistance from 
the list and/or IRC.

>
> However, if I subclass, then I (or someone) would end up writing
> Dancer2::Plugin::DBIC::Algebra (or whatever the naming ends up being),
> and so on for everything else that turns DBIC into a plugin (and I
> understand this set to be non-trivial).

I am not sure what you mean by this. Any "dbic backend integration" 
worth its salt simply takes a Schema class which provides the entire 
related graph of Results and Resultsets. This is the case for 
Dance2::Plugin::DBIC as well - all a user provides is 'schema_class'.

Your relational algebra plugin has no bearing on such an orthogonal 
concept as "web framework model" - your users would simply 
'load_components()' your plugin as part of their base resultset class.

>
> So. What's the best way to proceed? Just get coding and submit a
> patchset? Is there a more-established way to get on-board? Some kind
> of pre-approval process?

If you are asking "how would I go about including this experiment into 
the core DBIx::Class::Resultset class" - the answer is simply: this can 
not happen. Due to the sheer amount of code in the wild that slings 
around resultset objects, the base class overloads are effectively 
forever frozen like the rest of the API.

However as I described in the rest of my reply - the immutability of 
DBIx/Class/ResultSet.pm is of little consequence. Your idea belongs 
squarely in an extension/component, which due to DBIC's design is rather 
natural and least-effort way to gain extra functionality.

For extra inspiration look through this library of ResultSet components:
https://metacpan.org/source/FREW/DBIx-Class-Helpers-2.032000/lib/DBIx/Class/Helper/ResultSet

Feel free to ask further questions - the underlying work is very 
interesting!

Cheers