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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
